Database Reference
In-Depth Information
On caching
Yet another place where server-side programming can be used is for caching values,
which are expensive to compute. The basic pattern here is:
1. Check if the value is cached.
2. If not or the value is too old, compute and cache it.
3. Return the cached value.
For example, calculating sales for a company is the perfect item to cache. Perhaps,
a large retail company has 1,000 stores with potentially millions of individual sales
transactions per day. If the corporate headquarters is looking for sales trends, it is
much more efficient if the daily sales numbers were precalculated at the store level
instead of summing up millions of daily transactions.
If the value is simple, like looking up a user's information from a single table based
on the user ID, you don't need to do anything. The value becomes cached in Post-
greSQL's internal page cache, and all lookups to it are so fast that even on a very fast
network most of the time spent doing the lookups are in the network, not in the actual
lookup. In such a case, getting data from a PostgreSQL database is as fast as getting
it from any other in-memory cache (like memcached) but without any extra overhead
in managing the cache.
Another use-case of caching is implementing materialized views. These are views
which are precomputed only when needed, not each time one selects from that view.
Some SQL databases have materialized views as a separate database object, but in
PostgreSQL you have to do it all yourself, using other database features for automat-
ing the whole process.
