Re: TOASTing smaller things

On 3/21/2007 2:05 PM, Tom Lane wrote:
> Chris Browne <cbbrowne(at)acm(dot)org> writes:
>> #define TOAST_DENOMINATOR 17
>> /* Use this as the divisor; current default behaviour falls from TOAST_DENOMINATOR = 4 */
>
>> #define TOAST_TUPLE_THRESHOLD^I\
>> ^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
>> say, TOAST.

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.

Certainly.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #