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

Re: Setting Shared Buffers , Effective Cache, Sort Mem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>, Pallav Kalva <pkalva(at)deg(dot)cc>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Setting Shared Buffers , Effective Cache, Sort Mem
Date: 2004-04-24 02:50:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> [ on setting shared_buffers = half of RAM ]

> One minor detail...  You wouldn't really cache the _exact_ same blocks
> because cache-hits in shared-buffers (on the most frequently accessed
> pages) would let the OS cache some other pages in it's cache.

> But in my experience Manfred's right that there's no benefit and
> some penalty to making shared_buffers so large it takes a significant
> piece away from the OS's caching.

True, it'd probably not be the *exact* worst case.  But it'd be a good
approximation.  In practice you should either bet on the kernel doing
most of the caching (in which case you set shared_buffers pretty low)
or bet on Postgres doing most of the caching (in which case you set
shared_buffers to eat most of RAM).

The conventional wisdom at this point is to bet the first way; no one
has shown performance benefits from setting shared_buffers higher than
the low tens of thousands.  (Most of the mail list traffic on this
predates the existence of pgsql-performance, so check the other list
archives too if you go looking for discussion.)

It's possible that Jan's recent buffer-management improvements will
change the story as of 7.5.  I kinda doubt it myself, but it'd be worth
re-running any experiments you've done when you start working with 7.5.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2004-04-24 02:58:24
Subject: Re: Help with performance problems
Previous:From: brad-pgperfDate: 2004-04-23 22:21:21
Subject: index usage

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