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.schuller@xxxxxxxxxxxx>' > Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx > E-Mail: peter.schuller@xxxxxxxxxxxx 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
