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
