mlw <markw@mohawksoft.com> writes:
> "Server" would have a huge number of buffers,
Do you have any evidence whatsoever that that's actually a good idea?
Certainly the existing default configuration is ridiculously cramped
for modern machines. But I've always felt that NBuffers somewhere in
the low thousands should be plenty. If you have lots of main memory
then the kernel can be expected to use it for kernel-level disk
buffering, which should be nearly as good as buffering inside Postgres.
(Maybe better, considering that we have some routines that scan all our
buffers linearly ...) Moreover, if you request a huge chunk of shared
memory then you run a significant risk that the kernel will decide to
start swapping parts of it, at which point it definitely becomes a
loser. Swapping a dirty buffer out and back in before it finally gets
written to disk is counterproductive. You want to keep the number of
buffers small enough that they all stay pretty "hot" in the swapper's
eyes.
Basically, I think that it's best to give the kernel plenty of elbow
room to deal with memory pressures on its own terms. Even on a machine
that's nominally dedicated to running Postgres.
Awhile back I suggested raising the default configuration to 1000 or
so buffers, which would be slightly less silly than the current default
even if it's not optimal. Didn't get much feedback about the idea
though.
regards, tom lane
