On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > The complication, opportunities for bugs, and general slowdown > associated with that would outweigh any possible gain, in the opinion > of most hackers who have thought about this.
I wouldn't be quite so pessimistic. I think the problem is that the hard part in doing this for real is all the parts the proposal glosses over. How much memory is it worth dedicating to the cache before the cost of that memory costs more than it helps? How do you invalidate cache entries efficiently enough that it doesn't become a bottleneck? Also, you need to identify the specific advantages you hope a built-in cache would have over one implemented in the ORM or database library. If there aren't any advantages then those solutions are much simpler. And they have other advantages as well -- one of the main reason people implement caches is so they can move the load away from the bottleneck of the database to the more easily scaled out application. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
