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

Re: PG 8.3 and large shared buffer settings

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, Dan Sugalski <dan(at)sidhe(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PG 8.3 and large shared buffer settings
Date: 2009-09-26 02:53:56
Message-ID: f67928030909251953o344b3963q766f0dba1509ea43@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Sep 25, 2009 at 8:53 AM, Scott Carey <scott(at)richrelevance(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Jeff JanesDate: 2009-09-26 03:06:42
Subject: Re: query memory consumption
Previous:From: Josh KupershmidtDate: 2009-09-25 21:22:41
Subject: Re: Regarding Sequential Scans count increase each time we press refresh .

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