pgsql@mohawksoft.com writes:
> A "persistent reference" index would be like almost any other index except
> that as new items are added to a table a new entry is added to the end of
> the index. When a row is updated, its CTID is updated in the table.
This *does not work* under MVCC: it can't cope with referencing
multiple simultaneously existing versions of a row. In general, any
index design that includes the words "update in place" can be rejected
out of hand.
In any case I still fail to see the advantage compared to an ordinary
serial primary key. You could have made your bitmaps reference the
serial numbers directly, instead of an intermediate table. (Either way
still fails to handle MVCC updates, unless the indexable attributes
cannot be changed by updates; but the intermediate table isn't helping
or hurting that.)
A bitmap that indexes CTIDs directly could work, because it doesn't need
to update any entries in-place when a table row is updated. I didn't
care for the details of Victor's design because (a) the intermediate
list of CTIDs looks bulky and (b) it seemed to require a lot of data
shuffling to cope with growth of the table. But in principle it would
work.
regards, tom lane
