Database Reference
In-Depth Information
and you should fill out the
destinationTable
parameter in the query
configuration. Note that when you use a named destination table, you must
pay for any storage the table uses, and the table never expires unless you
explicitly set an expiration time on the table.
The
writeDisposition
flag may come in handy when specifying the
destination table. Specifying
WRITE_APPEND
lets you append the results
to an existing table. If you want to overwrite an existing table completely,
you can specify
WRITE_TRUNCATE
instead. These operations happen
atomically; you can either see the table as it was before the query results get
written or you see all the results added to the table. If the query fails, the
table will not be modified at all.
Query Cache
BigQuery attempts to cache query results and returns results from the cache
whenever possible. If you run
SELECT COUNT(*) FROM
[publicdata:samples.wikipedia]
, the result is added to the cache. If
you run the same query a second time, you get the cached result. As a user
this is nice because you don't get charged for queries that hit the cache. You
also can get a result faster if you don't actually have to run the query. Cached
queries live for 24 hours after the last access.
Queries are cached per-user, so if you run a query and your coworker runs
the same query, she can't use your cached result. Having per-user caches
helps prevent both security and privacy issues.
Some types of queries cannot be cached. For example, if you run the query
SELECT NOW() + RAND()
, the query won't be cached because the result
is nondeterministic. Likewise, if you write the query results to a named
destination table, the results won't be cached because the results live in
the destination table rather than the cache. Finally, if the tables you query
against change, the cache will be purged.
If you don't want to allow your results to be cached, you can set
useQueryCache
to
false
when you run the query (either via
Jobs.insert()
or
Jobs.query()
). For the most part, you won't need
this flag; however, you might be explicitly trying to test performance without
using the cache, and you'll actually want to see how long the query takes to
run and how much data it processes. Queries that return cached results will
