On Fri, Mar 23, 2012 at 11:29 AM, Greg Stark <st...@mit.edu> wrote: > 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. > > Thanks for the input. I've had many of these thoughts myself, and I guess it depends on the environment the database will be used, memory settings, and other variables, on how valuable a query cache would be. I'll definitely give this more thought before sending an official proposal.
Billy
