Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> One thing this does bring up is that the maximum safe tuple length is
>> dependent on the index or table type. The toaster's API had better
>> be designed accordingly...
> In talking to Jan, the index code will make use of the toast entries
> automatically. He said the heap_insert will do any toasting, and after
> that the tuple already has any toast pointers, and that gets inserted
> into the index.
If that's his plan, then it's broken by design. Toasting a complete
tuple cannot be the basis for toasting index entries related to the
tuple, because (a) the index entries will typically use only some of the
fields appearing in the tuple; (b) index entries have different length
limits than tuples do; (c) indexes might be created after the original
table is. Heck, index *types* might be created after the original table
is. If index toasting is dependent on toasting of the main table, the
only way it can work is to toast every varlena attribute down to a
prechosen maximum length that Jan hopes will satisfy every index type,
now or hereafter --- no matter whether the column in question has or
ever will have an index of any type.
And that'll still crash and burn for multicolumn indexes.
I thought the plan was to toast indexes independently of the main
table, ie, an index would have its own toast-table and its own
storage of oversize attributes --- where the *index* decides what
is oversize, not the main table.
If main tables and indexes point at the same toast-table entries,
I think VACUUM will become rather an interesting problem, too...
although maybe that could be worked around if VACUUM destroys indexes
and rebuilds them from scratch.
regards, tom lane