bigquery.Table: Increase default maxResults 1024 -> 100000

[jdanbrown]

• Setting too low is slow (too many http reqs)
• Setting too high is safe (api enforces a max)
• Docs indicate that 100000 is the max allowed:
  • https://cloud.google.com/bigquery/docs/data

Test plan:

• Run a query that downloads a nontrivial amount of results

len(datalab.bigquery.Query('''
    select * from `bigquery-public-data`.noaa_gsod.gsod2016 limit 100000
''').to_dataframe(dialect='standard', use_cache=False))

• Before:
  • 86s
  • Log of http reqs: https://gist.github.com/jdanbrown/d979fa3b088b98a7070e0babac95eeae
• After:
  • 47s
  • Log of http reqs: https://gist.github.com/jdanbrown/a9a1b8373dc8dc3131d776eda2094b27

[yebrahim]

It's not clear whether this is a good idea for other scenarios when all is needed is to preview a page or two of the table. I think we need to think a little more about this. We might want to have two different defaults, one for iterating through the table (using cached pages), and one for getting the entire table contents, such as converting it to a dataframe.
@nikhilk @qimingj any thoughts here?

[yebrahim]

I think we should revisit this change in the context of googledatalab/datalab#1283. A larger page size would help in the case when the entire table is being brought down, for example into a dataframe. But in the case of a table iterator (calling __getitem__), or if a range of rows is requested, a smaller page size makes sense. Copying a page of size 1024 is significantly faster than a 100,000-row page.

@jdanbrown, would you be willing to work on this change to handle these two scenarios differently?

[jdanbrown]

@yebrahim I'd be happy to dig in and make the change, but I don't anticipate having time to do it in the next ~4w, so don't hesitate to jump in and do it first. Our team is using this PR as is for the time being.

[yebrahim]

Fixed in #339, closing this one.