Re: Bug: Buffer cache is not scan resistant

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@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)