| From: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Grzegorz Jaskiewicz" <gj(at)pointblue(dot)com(dot)pl>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Doug Rady" <drady(at)greenplum(dot)com>, "Sherry Moore" <sherry(dot)moore(at)sun(dot)com> |
| Subject: | Re: Bug: Buffer cache is not scan resistant |
| Date: | 2007-03-05 08:51:38 |
| Message-ID: | C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0C6@MI8NYCMAIL08.Mi8.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Tom,
> Even granting that your conclusions are accurate, we are not
> in the business of optimizing Postgres for a single CPU architecture.
I think you're missing my/our point:
The Postgres shared buffer cache algorithm appears to have a bug. When
there is a sequential scan the blocks are filling the entire shared
buffer cache. This should be "fixed".
My proposal for a fix: ensure that when relations larger (much larger?)
than buffer cache are scanned, they are mapped to a single page in the
shared buffer cache.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-03-05 09:09:32 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Tom Lane | 2007-03-05 08:45:17 | Re: Bug: Buffer cache is not scan resistant |