Re: TOASTing smaller things

On 3/21/2007 2:05 PM, Tom Lane wrote:
> Chris Browne <cbbrowne@acm.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@Yahoo.com #