[EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings