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: | 2006-03-29 21:49:45 |
Message-ID: | 1136.1143668985@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-29 22:04:19 | Re: control pg_hba.conf via SQL |
Previous Message | Jonah H. Harris | 2006-03-29 21:43:55 | Re: control pg_hba.conf via SQL |