On 3/21/2007 2:05 PM, Tom Lane wrote:
Chris Browne <[EMAIL PROTECTED]> writes:
#define TOAST_DENOMINATOR 17
/* Use this as the divisor; current default behaviour falls from TOAST_DENOMINATOR = 4 */
^IMAXALIGN_DOWN((BLCKSZ - \
^I^I^I^I MAXALIGN(sizeof(PageHeaderData) + 3 * sizeof(ItemIdData))) \
^I^I^I^I / TOAST_DENOMINATOR)
Given that you are quoting code that was demonstrably broken since the
original coding of TOAST up till a month or two back, "it passes
regression" is not adequate proof of "it's right". In fact I think
it's not right; you have not got the roundoff condition straight.
4. A different mechanism would be to add a fifth storage column
strategy (the present four are PLAIN, EXTENDED, EXTERNAL, MAIN), let's
FORCE_COMPRESSION, FORCE_EXTERNAL and FORCE_EXTERNAL_UNCOMPRESSED.
Anything along this line would require invoking the toaster on every
single tuple, since we'd always have to crawl through all the columns
to see if toasting was supposed to happen. No thanks.
Not necessarily. A flag in Relation telling if the table has any column
marked like that could be set while constructing the relcache entry.
Which of these sounds preferable?
It's a bit late in the cycle to be proposing any of these for 8.3.
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster