Let's talk a little bit more about Query Cache. This is this magical concept of creating those really fast queries. Now if you have what's called a deterministic query, if at runtime you don't know what the answer is, like if you're pulling things like the current time stamp for example, you can't rely on cache, right? Because that's something that's going to be changing depending upon when you're running it and then naturally that can't be cached. So let's take an example and see what that looks like. So here we're going to pull the current time stamp. And you can just do that at any time and we'd give this an alias. If you just want to just highlight the current record, you can just execute that as selected, and you can see zero bytes processed. And we're going to see if we can trigger that cache. And as you can see that cache is not going to come up because we have a deterministic query in the results that are going to change over time naturally as we expect. So you can't cache the current time because the current time is constantly changing underneath you as you're trying to query it, right? So that makes sense. And you could also disable cache in the Show Options and reasons why you might want to do that. Now naturally, cache is already what we call broken or busted. Cache is busted when the underlying tables themselves have been updated. So if there was a data change in the table, what BigQuery will do is it will compare the time stamps from when you ran that last query, what was that table last modified date? If that has since changed, then it will automatically be smart enough to not rely on the Query Cache and will invalidate that cache, but you can manually do it yourself inside of the Show Options should you want. Say, if you're timing a query for performance reasons, you don't necessarily want to rely on cache as it might not always be there.
