"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> Neil suggested a very good way how to handle updates. Of course, it's not
> necessary to strictly follow tuple layout in the table's heap, as I wanted
> to do initially. All that's needed, is that bit positions in bitmaps would
> be tied with CTID positions in LOC.
> So, we can do simple insert (generally, that's how MVCC works for tuple
> updates): when some tuple is updated, new CTID is added to the LOC and each
> bitmap is extended by 1 bit.
The other stuff you mentioned implies that an insertion therefore
requires exclusive lock on the index (because you may have to relocate
everything in sight to add one more CTID slot).
> On the other side (as Neil pointed), after VACUUM, we need to do some
> maintenance of bitmap index to avoid situations when index contains duplicate
> entries (in LOC and bitmaps) for the same CTID (value before marking tuple for
> reuse and after actually reusing it). So far, the fastest way would be
> recreating index,
I can't believe you are seriously suggesting that it's OK to force every
VACUUM to rebuild the index from scratch. We already get far too many
complaints about the time needed for VACUUM.
I don't think we really need any more fundamentally nonconcurrent index
types :-(
> I've started to implement AM, I need to register am* functions, what OIDs
> should use to register them in include/catalog/pg_proc.h?
Anything the unused_oids script reports as free.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
