| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
| Cc: | "Sherry Moore" <sherry(dot)moore(at)sun(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Pavan Deolasee" <pavan(at)enterprisedb(dot)com>, "Gavin Sherry" <swm(at)alcove(dot)com(dot)au>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Doug Rady" <drady(at)greenplum(dot)com> |
| Subject: | Re: Bug: Buffer cache is not scan resistant |
| Date: | 2007-03-13 05:16:04 |
| Message-ID: | C21B81A4.292B3%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon,
You may know we've built something similar and have seen similar gains.
We're planning a modification that I think you should consider: when there
is a sequential scan of a table larger than the size of shared_buffers, we
are allowing the scan to write through the shared_buffers cache.
The hypothesis is that if a relation is of a size equal to or less than the
size of shared_buffers, it is "cacheable" and should use the standard LRU
approach to provide for reuse.
- Luke
On 3/12/07 3:08 AM, "Simon Riggs" <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, 2007-03-12 at 09:14 +0000, Simon Riggs wrote:
>> On Mon, 2007-03-12 at 16:21 +0900, ITAGAKI Takahiro wrote:
>
>>> With the default
>>> value of scan_recycle_buffers(=0), VACUUM seems to use all of buffers in
>>> pool,
>>> just like existing sequential scans. Is this intended?
>>
>> Yes, but its not very useful for testing to have done that. I'll do
>> another version within the hour that sets N=0 (only) back to current
>> behaviour for VACUUM.
>
> New test version enclosed, where scan_recycle_buffers = 0 doesn't change
> existing VACUUM behaviour.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2007-03-13 08:44:43 | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
| Previous Message | Sean Utt | 2007-03-13 05:05:58 | Re: My honours project - databases using dynamically attached entity-properties |