| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2009-09-26 03:06:42 | Re: query memory consumption |
| Previous Message | Josh Kupershmidt | 2009-09-25 21:22:41 | Re: Regarding Sequential Scans count increase each time we press refresh . |