From: | Steve <cheetah(at)tanabi(dot)org> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Question about memory allocations |
Date: | 2007-04-13 03:57:24 |
Message-ID: | Pine.GSO.4.64.0704122355360.17955@kittyhawk.tanabi.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> I didn't notice anyone address this for you yet. There is a tool in
> contrib/pg_buffercache whose purpose in life is to show you what the shared
> buffer cache has inside it. The documentation in that directory leads
> through installing it. The additional variable you'll likely never know is
> what additional information is inside the operating system's buffer cache.
Okay -- thanks! I'll take a look at this.
>> # Leaving this low makes the DB complain, but I'm not sure what's #
>> reasonable.
>> checkpoint_segments = 128
>
> That's a reasonable setting for a large server. The main downside to setting
> it that high is longer recovery periods after a crash, but I doubt that's a
> problem for you if you're so brazen as to turn off fsync.
Hahaha yeah. It's 100% assumed that if something goes bad we're
restoring from the previous day's backup. However because the DB is read
only for -most- of the day and only read/write at night it's acceptable
risk for us anyway. But good to know that's a reasonable value.
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-13 04:38:11 | Re: Strangely Variable Query Performance |
Previous Message | Steve | 2007-04-13 03:55:00 | Re: Strangely Variable Query Performance |