<br /><br /><div class="gmail_quote">On Fri, Mar 23, 2012 at 11:29 AM, Greg Stark <span dir="ltr"><<a
href="mailto:stark@mit.edu">stark@mit.edu</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px#ccc solid;padding-left:1ex"><div class="im">On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> > The complication, opportunities for bugs,
andgeneral slowdown<br /> > associated with that would outweigh any possible gain, in the opinion<br /> > of most
hackerswho have thought about this.<br /><br /></div>I wouldn't be quite so pessimistic. I think the problem is that
the<br/> hard part in doing this for real is all the parts the proposal glosses<br /> over. How much memory is it worth
dedicatingto the cache before the<br /> cost of that memory costs more than it helps? How do you invalidate<br /> cache
entriesefficiently enough that it doesn't become a bottleneck?<br /><br /> Also, you need to identify the specific
advantagesyou hope a built-in<br /> cache would have over one implemented in the ORM or database library.<br /> If
therearen't any advantages then those solutions are much simpler.<br /> And they have other advantages as well -- one
ofthe main reason<br /> people implement caches is so they can move the load away from the<br /> bottleneck of the
databaseto the more easily scaled out application.<br /><span class="HOEnZb"><font color="#888888"></font></span><br
/></blockquote></div>Thanksfor the input. I've had many of these thoughts myself, and I guess it depends on the
environmentthe database will be used, memory settings, and other variables, on how valuable a query cache would be.
I'lldefinitely give this more thought before sending an official proposal.<br /><br />Billy<br />
