Date: Fri, 23 Feb 2007 13:11:37 -0500
From: Bill Moran <wmoran@collaborativefusion.com>
To: "Campbell, Lance" <lance@uiuc.edu>
Cc: "Richard Huxton" <dev@archonet.com>,
  pgsql-performance@postgresql.org
Subject: Re: Recommended Initial Settings
Message-Id: <20070223131137.06824192.wmoran@collaborativefusion.com>
In-Reply-To: <A3AC4FA47DC0B1458C3E5396E685E63302395CE9@SAB-DC1.sab.uiuc.edu>
References: <A3AC4FA47DC0B1458C3E5396E685E63302395CE7@SAB-DC1.sab.uiuc.edu>
	<45DF1660.101@archonet.com>
	<A3AC4FA47DC0B1458C3E5396E685E63302395CE9@SAB-DC1.sab.uiuc.edu>
Organization: Collaborative Fusion
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In response to "Campbell, Lance" <lance@uiuc.edu>:

> Richard,
> Thanks for your reply.  
> 
> You said:
> "Your operating-system should be doing the caching for you."
> 
> My understanding is that as long as Linux has memory available it will
> cache files.  Then from your comment I get the impression that since
> Linux would be caching the data files for the postgres database it would
> be redundant to have a large shared_buffers.  Did I understand you
> correctly?

Keep in mind that keeping the data in the kernel's buffer requires
Postgres to make a syscall to read a file, which the kernel then realizes
is cached in memory.  The kernel then has to make that data available
to the Postgres (userland) process.

If the data is in Postgres' buffers, Postgres can fetch it directly, thus
avoiding the overhead of the syscalls and the kernel activity.  You still
have to make sysvshm calls, though.

So, it depends on which is able to manage the memory better.  Is the
kernel so much more efficient that it makes up for the overhead of the
syscalls?  My understanding is that in recent versions of Postgres,
this is not the case, and large shared_buffers improve performance.
I've yet to do any in-depth testing on this, though.

-- 
Bill Moran
Collaborative Fusion Inc.