From: | Billy Earney <billy(dot)earney(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: query cache |
Date: | 2012-03-23 16:41:39 |
Message-ID: | CAB1ii-dpb9xasJpSvk1BBkko+_jT7My3kaE=qor3brfheWry4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 23, 2012 at 11:29 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-03-23 16:42:51 | Re: Reporting WAL file containing checkpoint's REDO record in pg_controldata's result |
Previous Message | Greg Stark | 2012-03-23 16:29:28 | Re: query cache |