Database Reference
In-Depth Information
Set maxResults on Your Queries
If you set the maxResults flag on a query to a value that isn't too large
(say, 1000 results), you reduce the chances of hitting a connection
error. Large HTTP responses can fail in many different places and
many different ways; if you request smaller results you can always go
back and fetch more. Most of the time, you actually are only interested
in the first few results; requesting more is just going to take longer to
download.
It is easy to confuse the maxResults field with the LIMIT keyword in
the query. The LIMIT keyword controls how many results are
computed by the query engine and stored in the result table. The
maxResults field controls only how many results are returned in the
first page of results. Your query might return many more rows, which
would be stored in the query result temporary table in BigQuery. For
example, if your query returned a million rows and you set
maxResults to 10, Jobs.query() would return only the first 10 rows.
You can page through the rest, however, by calling
Jobs.getQueryResults() .
There is also an API design-related reason that Jobs.query() is a POST
operation instead of a GET . HTTP GET requests are not supposed to make
any state changes. They can be crawled, pre-fetched, cached, are susceptible
to double-dispatch, and so on. However, running a query can cost you
money. It would not seem right to have an HTTP GET run up a bill, so the
Jobs.query() method is exposed as a POST operation, not a GET .
Table 7.1 shows the fields that are returned in the Jobs.query() method:
 
Search WWH ::




Custom Search