Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group