Re: Postgres 7.3.1 poor insert/update/search performance - Mailing list pgsql-performance

From Tom Lane
Subject Re: Postgres 7.3.1 poor insert/update/search performance
Date
Msg-id 19952.1043251798@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postgres 7.3.1 poor insert/update/search performance  (Brian Hirt <bhirt@mobygames.com>)
List pgsql-performance
Brian Hirt <bhirt@mobygames.com> writes:
> So my question is:  if the kernel is caching all this data, what's the
> benefit of setting this to 1000 or higher?   Why wouldn't i just set it
> to 0 if I believe my kernel is doing a good job.

Well, setting it to 0 won't work ;-).  There's some minimum number of
buffers needed for PG to work at all; depending on complexity of your
queries and number of active backends it's probably around 25-100.
(You'll get "out of buffers" failures if too few.)  But more to the
point, when shared_buffers is too small you'll waste CPU cycles on
unnecessary data transfers between kernel and user memory.  It seems to
be pretty well established that 64 is too small for most applications.
I'm not sure how much is enough, but I suspect that a few thousand is
plenty to get past the knee of the performance curve in most scenarios.

            regards, tom lane

pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Postgres 7.3.1 poor insert/update/search performance
Next
From: Stephan Szabo
Date:
Subject: Re: [GENERAL] optimizing query