Re: PG 8.3 and large shared buffer settings - Mailing list pgsql-performance

From Jeff Janes
Subject Re: PG 8.3 and large shared buffer settings
Date
Msg-id f67928030909251953o344b3963q766f0dba1509ea43@mail.gmail.com
Whole thread Raw
In response to Re: PG 8.3 and large shared buffer settings  (Scott Carey <scott@richrelevance.com>)
Responses Re: PG 8.3 and large shared buffer settings  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-performance
On Fri, Sep 25, 2009 at 8:53 AM, Scott Carey <scott@richrelevance.com> wrote:
> That won't work well anyway because the postgres shared_buffers dos not cache
> things that are sequentially scanned (it uses a ring buffer for each scan).  So, for
> any data that is only accessed by sequential scan, you're relying on the OS and
> the disks.  If you access a table via index scan though, all its pages will go through
> shared_buffers.

Does it doe this even if the block was already in shared_buffers?
That seems like a serious no-no to me to read the same block into
different buffers.  I thought that the sequential scan would have to
break stride when it encountered a block already in buffer.  But I
haven't looked at the code, maybe I am over analogizing to other
software I'm familiar with.

Jeff

pgsql-performance by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: PG 8.3 and large shared buffer settings
Next
From: Jeff Janes
Date:
Subject: Re: query memory consumption