From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to keep a table in memory? |
Date: | 2007-11-13 19:36:14 |
Message-ID: | Pine.GSO.4.64.0711131230300.8434@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
I see this as similar to the old optimizer hint argument, where there
certainly exist some edge cases where people know something the optimizer
doesn't which changes the optimal behavior.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-11-13 19:42:18 | Re: fulltext parser strange behave |
Previous Message | Greg Smith | 2007-11-13 19:19:25 | Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris |