I doubt pinning buffers ever improve system on any halfway modern system. It will often *look* like it has improved performance because it improves the performance of the queries you're looking at -- but at the expense of slowing down everything else.
There is a use case it would be useful for though. When you have some queries that are latency critical. Then you might want to pin the buffers those queries use to avoid having larger less urgent queries purge those buffers.
If we had a way to mark latency critical queries that might be a more flexible interface but ewe would need some way to control just how critical they are. we wouldn't want to keep those buffets pinned forever.
greg
On 7 Feb 2010 07:36, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
Greg Smith <greg@2ndquadrant.com> writes:
> ... Part of the reason this feature
> hasn't been been perceived as more valuable is because just letting the
> two cache levels involv...Or to put it even more clearly: the only way that pinning particular
tables into RAM could beat letting the caching algorithm take care of
it is if the caching algorithm is seriously suboptimal. Therefore,
it would make more sense to put development effort into improving
the cache algorithm than to put it into giving the DBA a rather blunt
instrument for overriding the cache algorithm. We've already made
several rounds of improvements of that kind, and are quite happy to
consider more.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs...