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.
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.
That should be doable, if you only change the head of the SITC on
VACUUM. I'm not sure if that's what's being suggested right now.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
