Alvaro Herrera <[EMAIL PROTECTED]> writes:
> As for other indexes, I'm not sure why you say this precludes the use of
> other indexes. The only thing they have to do is keep pointers to index
> elements, instead of heap elements. Doesn't sound impossible to me.
However, btree feels free to move index entries around while inserting
other entries. I'm not sure that you could usefully use "ctid" as an
identifier for tuples in a btree-organized heap. This will break more
things than just other indexes :-( ... UPDATE chaining for one example.
> Another thing to keep in mind: L&Y requires unique keys. In the
> current btree implementation this is worked around using the
> pointers-to-heap (ctid?) to differentiate items that have the same key.
> If you use a clustered index you won't have this pointer; maybe it will
> be required that this index is marked UNIQUE.
IIRC this assumption is really only used when re-finding the parent
downlink after a page split, and so we were able to get rid of it by
looking for the downlink by child block number, without using the key at
all. So that part doesn't bother me. The mutability of index ctids
seems like a much worse problem.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
