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.
> 2. Alternatively, the index scan could store the location of the last
> known non-deletable tuple it has encountered, in addition to the tuple it
> stops on. When a stopped scan continues, it checks if the tuple it was
> stopped on is still on the same page. If it's not, instead of moving
> right to find it, relocate the last known non-deletable tuple and
> continue the scan from there. There can't be any visible tuples between
> the tuple it stopped on and the last known non-deletable tuple, because
> we would have encountered it before, and would know by now that it's
> non-deletable.
This one appears to be assuming MVCC visibility semantics, which means
it will break system catalog operations, and probably foreign-key checks
too.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
