Re: vacuum, performance, and MVCC

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Mon, Jun 26, 2006 at 11:29:27AM -0400, Bruce Momjian wrote:
> > > Yes, and for index_getmulti (which doesn't visit the heap at all) we'll
> > > have to change all the users of that (which aren't many, I suppose).
> > > It's probably worth making a utility function to expand them.
> > > 
> > > I'm still confused where bitmap index scan fit into all of this. Is
> > > preserving the sequential scan aspect of these a goal with this new
> > > setup?
> > 
> > No.  I was just pointing out that if you get to the tuple via an index,
> > you get handed the head of the SITC via the index tuple, but if you are
> > doing a sequential scan, you don't get it, so you have to find it, or
> > any other non-visible SITC header.
> 
> Ok, but it remains true that you can only have one SITC per tuple. So
> if you have 5 indexes on a table, any SITC will only join tuples that
> didn't change any values in any of the indexed columns. That's probably
> not a big deal though; indexes columns arn't likely to be the ones
> changing much.

Right.

> So, for the bitmap scan you have to make sure that within a single
> transaction, scanning multiple indexes will have to provide the same
> SITC for each set of tuples, even in the face of concurrent updates.
> Otherwise the BitmapAnd will incorrectly throw them out.

The index points to the item id on the page, and that never changes,
even if the head tuple changes later.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +