Tom, are you going to do this for 8.3?
---------------------------------------------------------------------------
Tom Lane wrote:
> In another thread I wrote:
> > ... One thing I was just thinking about is that it's silly to have
> > the threshold constrained so strongly by a desire that tuples in toast
> > tables not be toastable. It would be trivial to tweak the heapam.c
> > routines so that they simply don't invoke the toaster when relkind is
> > 't', and then we could have independent choices of toast-tuple size and
> > main-tuple size. This would be particularly good because in the current
> > scheme you can't modify toast-tuple size without an initdb, but if that
> > were decoupled there'd be no reason not to allow changes in the
> > main-tuple thresholds.
>
> After thinking about this more I'm convinced that the above is a good
> idea, eg in heap_insert change
>
> if (HeapTupleHasExternal(tup) || tup->t_len > TOAST_TUPLE_THRESHOLD)
> heaptup = toast_insert_or_update(relation, tup, NULL, use_wal);
> else
> heaptup = tup;
>
> to
>
> if (relation->rd_rel->relkind == RELKIND_TOASTVALUE)
> {
> /* toast table entries should never be recursively toasted */
> Assert(!HeapTupleHasExternal(tup));
> heaptup = tup;
> }
> else if (HeapTupleHasExternal(tup) || tup->t_len > TOAST_TUPLE_THRESHOLD)
> heaptup = toast_insert_or_update(relation, tup, NULL, use_wal);
> else
> heaptup = tup;
>
> I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
> compiled-in parameters that are recorded in pg_control and checked for
> compatibility at startup (like BLCKSZ) --- this will prevent anyone from
> shooting themselves in the foot while experimenting.
>
> Any objections?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +