"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
