> 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
Yes, I see your point. This could be quite complicated. He is
targeting BLKSZ and indexes are BLKSZ/3. He could toast any single
attribute of size >= BLKSZ/3, but as you mentioned multi-column
indexes would be a problem. I wonder if he could create the TOAST
entries and modify the heap tuple during index creation?
Wow, this clearly is going to be messy. Maybe he is going to have to
have a separate TOAST table for the index. If he got fancy, he could
use the heap TOAST table as needed, and have a secondary index TOAST for
cases the tuple needs further TOASTS for indexes.
It shows we haven't thought through all this yet.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
