On Fri, Jul 12, 2002 at 02:38:16PM +0900, Curt Sampson wrote:
> Also, note that I am not advocating the very minimal number of buffers;
> you do want enough to ensure that, say, a bunch of simultaneous update
> requests that touch various data and index pages several times during
> the update can have all of those buffers remain in postgres' shared
> memory.
The problem with this approach is that if there are some tables which
get hit much less frequently than others, but which are crucial for
an application, decreasing the buffer size means that they'll need,
at the very least, to be copied from OS buffers.
The cost of that is significant, as I believe I noted recently, if
you're trying to shave milliseconds off your query times: lots of
microseconds add up.
The real answer to that problem, of course, is being able to lock
certain tables in memory. But in the absence of such a feature, a
little experimenting might reveal that very large buffers are called
for.
I think the administrator docs have it right: the only way to set the
value correctly is by experimentation; a rule of thumb, used
uncritically, is as likely as not to cause that digit to be under the
hammer head.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
