Comparison
Bytes scannedvsResult cache
Bytes scanned
the query returned four rows and the console says it read two point one terabytes.
How much data a query actually read from storage, which on most modern warehouses is what you are billed for. It is the number to optimise rather than runtime, because a fast query on a large scan is still expensive and caching makes runtime a liar. It also makes the effect of layout legible: the same query on the same data can differ by three orders of magnitude in bytes scanned depending on partitioning and column selection.
Full entry →Result cache
the second person to run the identical query got the answer instantly and was charged nothing.
Reusing a previously computed result for a byte-identical query when the underlying data has not changed. It makes repeated dashboard loads nearly free and it makes benchmarking treacherous, because the second run of anything is not measuring what you think. Its invalidation is coarse — any write to a referenced table drops it — so on frequently updated tables it does much less than people assume.
Full entry →