Josh Berkus wrote:
1) Query caching is not a single problem, but rather several different problems requiring several different solutions.
2) Of these several different solutions, any particular query result caching implementation (but particularly MySQL's) is rather limited in its applicability, partly due to the tradeoffs required. Per your explanation, Oracle has improved this by offering a number of configurable options.
3) Certain other caching problems would be solved in part by the ability to construct "in-memory" tables which would be non-durable and protected from cache-flushing. This is what I'm interested in chatting about.
Just my 2 cents on this whole issue. I would lean towards having result caching in pgpool versus the main backend. I want every ounce of memory on a database server devoted to the database. Caching results would double the effect of cache flushing ... ie, now both the results and the pages used to build the results are in memory pushing out other stuff to disk that may be just as important.
If it was in pgpool or something similar, I could devote a separate machine just for caching results leaving the db server untouched.
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
