Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> One idea that may be closer to reality might be implementing heaps that
> behave as indexes (or indexes that behave as heaps), or clustered
> indexes as some other database call them; the main idea being that at
> the leaf nodes of the index, the whole heap tuple resides instead of
> only a CTID.
The main problem with this is that you'd not have a stable TID for a
given tuple, since it might be forced to move by operations such as
index page splits. It might be impractical to support any secondary
indexes on such a table --- but I can definitely see that there are
applications that wouldn't care.
> One problem I see with that approach is the maximum tuple size ... our
> current btree index code can't handle tuples bigger than (BLCKSZ/3)
> IIRC, some 2 kB.
So you toast 'em ... I don't see this as a fatal drawback.
regards, tom lane
