On Wed, 2006-03-29 at 16:49 -0500, Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > 1. Instead of stopping on the first matching tuple, scan the whole index > > page for all matching entries at once. > > That loses the ability to reflect tuple deadness back into LP_DELETE > flags, no? Which is a problem already for bitmap indexscans, but I > don't wish to give it up for regular indexscans too. With a solution > for that it might be workable, but I don't see what we do about that.
OK, I was thinking this would mean we'd need to scan the whole page making this less efficient for nearly unique index access. But it doesn't at all - we can still probe to start and scan from there. Sequential access within the block would mean hardware cache prefetch would kick-in for many scans. If we did do this, the access would be so much more efficient that we would have enough time to take additional actions to record LP_DELETE flags, when dead tuples exist. Certainly it would be better to make a single return visit to the block and record *all* LP_DELETEs found in one go, rather than dirty the block once for each index_getnext and potentially have it written out more than once as we scan it. Perhaps use a heuristic of if > 3 LP_DELETEs found make a return visit to the block to set them. Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster