From: Nikolas Everett <nik9000@gmail.com>
To: Pierre C <lists@peufeu.com>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Dave Crooke <dcrooke@gmail.com>
Cc: Paul McGarry <paul@paulmcgarry.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: shared_buffers advice
Date: Tue, 16 Mar 2010 09:26:15 -0400
Message-ID: <d4e11e981003160626o6c76d902t16073cabb4dadabc@mail.gmail.com> (raw)
In-Reply-To: <op.u9nrbeeteorkce@localhost>
References: <a056b1d41003101728h2bfe964cg43bf5ef1aabae14d@mail.gmail.com>
<ca24673e1003152217q117b0fd3q7d2d75ff20185c8b@mail.gmail.com>
<4B9F3302.4020900@2ndquadrant.com>
<op.u9nrbeeteorkce@localhost>
On Tue, Mar 16, 2010 at 7:24 AM, Pierre C <lists@peufeu.com> wrote:
>
> I wonder about something, too : if your DB size is smaller than RAM, you
> could in theory set shared_buffers to a size larger than your DB provided
> you still have enough free RAM left for work_mem and OS writes management.
> How does this interact with the logic which prevents seq-scans hogging
> shared_buffers ?
I think the logic you are referring to is the clock sweep buffer accounting
scheme. That just makes sure that the most popular pages stay in the
buffers. If your entire db fits in the buffer pool then it'll all get in
there real fast.
Two things to consider though:
1. The checkpoint issue still stands.
2. You should really mess around with your cost estimates if this is the
case. If you make random IO cost the same as sequential IO postgres will
prefer index scans over bitmap index scans and table scans which makes sense
if everything is in memory.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: nik9000@gmail.com, lists@peufeu.com, greg@2ndquadrant.com, dcrooke@gmail.com, paul@paulmcgarry.com
Subject: Re: shared_buffers advice
In-Reply-To: <d4e11e981003160626o6c76d902t16073cabb4dadabc@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox