From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Michael van Rooyen <mvanr(at)bigfoot(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Kernel cache vs shared_buffers |
Date: | 2007-05-12 14:28:45 |
Message-ID: | 4645CF1D.1030309@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Michael van Rooyen wrote:
> I have no idea regarding the inner working of the pg's shared cache, but
> what I would like to find out is whether it is table-row-based, or
> disk-block-based.
It's block based.
> In the case of it being disk-block based, my
> inclination would be to let the kernel do the buffering. In the case of
> the cache being table-row-based, I would expect it to be much more
> space-efficient and I would be inclined to give the memory to the pg.
> In that case, is it feasible to set shared_buffers to something like
> 500000 x 8k blocks? We make extensive use of indexes on the larger
> tables and would seldom, if ever, do sequential scans.
A common rule of thumb people quote here is to set shared_buffers to 1/4
of available RAM, and leave the rest for OS cache. That's probably a
good configuration to start with.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2007-05-12 16:51:18 | Re: estimating the need for VACUUM FULL and REINDEX |
Previous Message | Michael van Rooyen | 2007-05-12 11:10:12 | Kernel cache vs shared_buffers |