"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> If I push the TOAST_TUPLES_PER_PAGE up to 16 I get another failure on the same
>> line from trying to toast a sequence. If I add RELKIND_SEQUENCE to the
>> assertion then it passes all regression tests even if I push
>> TOAST_TUPLES_PER_PAGE up to 1024 -- ie, try to toast everything as far as
>> possible. Perhaps heapam.c:1761 should just check for RELKIND_SEQUENCE as
>> well.
>
> Hmm. I'm inclined to reverse the tests (there are 3 not just 1) in
> heapam.c, so that it explicitly tries to toast only in plain tables,
> rather than adding more exclusion cases. Thoughts?
Well RELKIND_UNCATALOGED can be usefully toasted in that data can be
compressed internally. I suppose we know none normally receive such treatment
at normal block sizes. If we want to make the tuple threshold configurable
down the line would we want it affecting initdb bootstrapping? My experiments
show it isn't a problem but I don't particularly see any reason why it's
advantageous.
We may want some future relkinds to be toastable but I don't see a problem
adding new cases to the test.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
