On Fri, Feb 15, 2008 at 01:35:29PM +0100, Peter Schuller wrote:
> my impression has been that in the past, there has been a general
> semi-consensus that upping shared_buffers to use the majority of RAM
> has not generally been recommended, with reliance on the buffer cache
> instead being the recommendation.
> Given the changes that have gone into 8.3, in particular with regards
> to minimizing the impact of large sequential scans, would it be
> correct to say that given that
> - enough memory is left for other PG bits (sort mems and whatnot else)
> - only PG is running on the machine
> - you're on 64 bit so do not run into address space issues
> - the database working set is larger than RAM
> it would be generally advisable to pump up shared_buffers pretty much
> as far as possible instead of relying on the buffer cache?
> / Peter Schuller
> PGP userID: 0xE9758B7D or 'Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>'
> Key retrieval: Send an E-Mail to getpgpkey(at)scode(dot)org
> E-Mail: peter(dot)schuller(at)infidyne(dot)com Web: http://www.scode.org
PostgreSQL still depends on the OS for file access and caching. I
think that the current recommendation is to have up to 25% of your
RAM in the shared buffer cache.
In response to
pgsql-performance by date
|Next:||From: Peter Schuller||Date: 2008-02-15 13:58:46|
|Subject: Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PGmachine|
|Previous:||From: Peter Schuller||Date: 2008-02-15 12:35:29|
|Subject: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine|