> > What I have found, on a machine that is doing mostly DBMS servering
> > if you have a small shared buffer you will see that the CPU is
> > not fully utilized as it is waiting on I/O a lot of the time.
Just to repeat what curt said :-) : This doesn't make sence to me.
Whatever memory you give to Postgres for caching *could* be used by the
OS to cache. It doesn't seem that changing PG's buffer count should
make any real difference in real disk IO; the disk pages will get cached
one way or the other.
> What OS are you using? Unless it's really strange or really old, you
> are probably just removing an operating system buffer for each shared
> memory buffer you add. (But this is not good; two smaller buffers in
> series are not as good as one big buffer.)
When are PG's buffers *not* in series with the OS's? *Any* page that
postgres has read from disk has been in the OS cache. When reading a
page that's not in either cache, you get:
[Disk] => <read> => [OS cache] => <mem copy> => [PG cache]
And when its in only the OS cache, you get:
[OS cache] => <mem copy> => [PG cache]
The bigger your PG cache, the less often you have to ask the OS for a
page. That <mem copy> (plus syscall overhead) that happens between OS
cache and PG cache is expensive compared to not having to do it. Not
horribly so, I realize, but every little bit helps...
Unless I'm just completely missing something here, the bigger the PG
cache the better, within reason. Please don't come back with a remark
about other processes needing memory and possible swap storms, etc.; I
know to avoid that, and my approach would need to be *heavily* curbed on
machines that do things besides run Postgres. But as long as there is
no danger of starving the machine for memory, I don't see what the harm
is in giving more memory to Postgres.
<snip snip>
--Glen Parker