| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Luke Lonergan <LLonergan(at)greenplum(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 20:19:51 |
| Message-ID: | 1173125991.13722.327.camel@dogma.v10.wvs |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2007-03-05 at 09:09 +0000, Heikki Linnakangas wrote:
> In fact, the pages that are left in the cache after the seqscan finishes
> would be useful for the next seqscan of the same table if we were smart
> enough to read those pages first. That'd make a big difference for
> seqscanning a table that's say 1.5x your RAM size. Hmm, I wonder if
> Jeff's sync seqscan patch adresses that.
>
Absolutely. I've got a parameter in my patch "sync_scan_offset" that
starts a seq scan N pages before the position of the last seq scan
running on that table (or a current seq scan if there's still a scan
going).
If the last scan is not still in progress, the pages are less likely to
be in cache. If the pages are in cache, great; if not, it doesn't matter
where we start anyway.
If the last scan is still in progress, those recently-read pages are
very likely to be in cache (shared buffers or OS buffer cache).
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-05 20:23:51 | Re: proposal: custom variables management |
| Previous Message | Tom Lane | 2007-03-05 20:18:47 | Re: Bug: Buffer cache is not scan resistant |