On Fri, 19 Aug 2005 19:12:11 +1000 Graeme Lee <[EMAIL PROTECTED]>
wrote:

> It was a suggestion.  And the shared buffer cache is still not a disk
> cache.

A bad suggestion, hence my correcting it.  I really hate seeing
misinformation in list archives, people do use them.  Yes, this is
fairly common misinformation about postgresql, even linked to from
their site unfortunately, but that doesn't make it true.

> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
> http://www.powerpostgresql.com/PerfList/

Guess what, those are wrong.  The first one says:
"PLEASE NOTE. PostgreSQL counts a lot on the OS to cache data files and
hence does not bother with duplicating its file caching effort."

But that would be incredibly stupid, and postgresql's performance
would suffer tremendously if it were true.  The postgresql source code
says that it does use the shared buffer cache to cache pages read from
disk, and I believe it over someone who also says things like "The real
analysis of the precise best setting is not fully understood"

This is absolute nonsense.  The shared buffer cache is well understood,
and the only way you will hurt performance by making it too big is by
using up so much RAM that you start hitting swap, or by making it
larger than your data plus the other usage.  Unless perhaps your OS
performs poorly with large shared memory allocations (does openbsd?).

> See above links

See src/backend/storage/buffer/bufmgr.c
or even just the README file there which refers to "shared disk
buffers", and explains about the replacement strategy used.  Yes, the
shared buffer cache stores queries from each connection until they are
executed, that's why the MINIMUM size is max_con * 2.  But it also
caches pages retrieved from disk, if you gave it more than the bare
minimum RAM required just to work at all.  The link you sent the first
time is correct:

"POSTGRESQL does not directly change information on disk. Instead, it
requests data be read into the POSTGRESQL shared buffer cache.
POSTGRESQL backends then read/write these blocks, and finally flush
them back to disk."

Or maybe the src/backend/storage/buffer/*.c code is an elaborate hoax
and doesn't really do anything?

Adam

Reply via email to