| From: | Jim Nasby <decibel(at)decibel(dot)org> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Luke Lonergan <LLonergan(at)greenplum(dot)com>, 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-06 04:02:27 |
| Message-ID: | 39501601-F6B1-4EA4-8B4B-FA1FB73A657F@decibel.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mar 5, 2007, at 2:03 PM, Heikki Linnakangas wrote:
> Another approach I proposed back in December is to not have a
> variable like that at all, but scan the buffer cache for pages
> belonging to the table you're scanning to initialize the scan.
> Scanning all the BufferDescs is a fairly CPU and lock heavy
> operation, but it might be ok given that we're talking about large
> I/O bound sequential scans. It would require no DBA tuning and
> would work more robustly in varying conditions. I'm not sure where
> you would continue after scanning the in-cache pages. At the
> highest in-cache block number, perhaps.
If there was some way to do that, it'd be what I'd vote for.
Given the partitioning of the buffer lock that Tom did it might not
be that horrible for many cases, either, since you'd only need to
scan through one partition.
We also don't need an exact count, either. Perhaps there's some way
we could keep a counter or something...
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2007-03-06 04:11:14 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Tom Lane | 2007-03-06 03:58:40 | Re: Bug: Buffer cache is not scan resistant |