Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PGmachine

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PGmachine
Date: 2008-02-15 13:37:34
Message-ID: 20080215133734.GU12156@it.is.rice.edu (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Feb 15, 2008 at 01:35:29PM +0100, Peter Schuller wrote:
> Hello,
> 
> 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
> 
Peter,

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.

Ken

In response to

Responses

pgsql-performance by date

Next:From: Peter SchullerDate: 2008-02-15 13:58:46
Subject: Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PGmachine
Previous:From: Peter SchullerDate: 2008-02-15 12:35:29
Subject: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group