Gregory Stark <stark@enterprisedb.com> writes:
> The reason I think this is idea is exciting is that later I would suggest
> applying it to HOT updates. Having to keep a spare tuple's worth of space in
> every page is pretty annoying. But if we could get by with the average
> half-tuple dead space to do an update-- or even several updates--it would make
> a huge difference.
Uh ... what? This proposal is about reducing WAL volume, not about
changing the live data storage.
>> Or maybe we just need to revisit the default toast
>> thresholds --- AFAIR there has never been any significant study of
>> the particular values that Jan picked originally.
> I agree that these values need a second look. I think a TOAST_TUPLE_THRESHOLD
> well smaller than the current value would still easily pay its way. With a
> little caution to avoid wasting too much effort on the last few bytes I
> suspect even as low as 400-500 bytes is probably worthwhile.
Maybe. 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.
> In fact looking at this code now, is there a bug here? I don't see anything in
> there stopping us from trying to toast varlenas that are smaller than a toast
> pointer. Have I just missed something obvious?
Note the initialization of biggest_size.
regards, tom lane
