Comparison
Cache invalidationvsResult cache
Cache invalidation
you changed the row and now you have to hunt down every cached copy of it before someone reads the old one.
The problem of removing or updating cached entries once the underlying data changes. It is hard because the set of cache keys derived from one row is rarely obvious: a single user update can invalidate their profile, three list pages, a search result and a rendered fragment. Most production bugs blamed on caching are really a key you forgot to invalidate.
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 →