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 [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
