Re: Index vacuum improvements
- From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
- Cc: pgsql-hackers(at)postgresql(dot)org
- Subject: Re: Index vacuum improvements
- Date: Wed, 29 Mar 2006 16:49:45 -0500
- Message-id: <1136.1143668985@sss.pgh.pa.us> <text/plain>
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> 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
Home |
Main Index |
Thread Index