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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
