From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to keep a table in memory? |
Date: | 2007-11-14 07:39:06 |
Message-ID: | 1195025946.4378.85.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2007-11-13 at 14:36 -0500, Greg Smith wrote:
> On Tue, 13 Nov 2007, Andrew Sullivan wrote:
>
> > I have to agree with what Tom says, however, about people thinking
> > they're smarter than the system. Much of the time, this sort of thumb
> > on the scale optimisation just moves the cost to some other place
>
> Sure, but in this case the reasoning seems sound enough. The buffer
> eviction policy presumes that all buffers cost an equal amount to read
> back in again. Here we have an application where it's believed that's not
> true: the data on disk for this particular table has a large seek
> component to it for some reason, it tends to get read in large chunks (but
> not necessairly frequently), and latency on that read is critical to
> business requirements. "The system" doesn't know that, and it's
> impractical to make it smart enough to figure it out on its own, so asking
> how to force that is reasonable.
It seems possible to imagine a different buffer eviction policy based
upon tablespace, block type, peak rather than latest usage pattern etc..
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-11-14 07:46:58 | Re: Simplifying Text Search |
Previous Message | Simon Riggs | 2007-11-14 06:25:12 | Re: Simplifying Text Search |