Greg Stark <stark@enterprisedb.com> wrote:
> On Thu, Jun 11, 2009 at 5:12 PM, Kevin
> Grittner<Kevin.Grittner@wicourts.gov> wrote:
>>
>> MAIN allows compression but discourages out-of-line storage.
>> (Out-of-line storage will be performed only if the row is still too
>> big after compression and out-of-line storage of EXTENDED and
>> EXTERNAL columns.)
>
> I had the impression the confusion was over the meaning of "too big"
> rather than what "last resort" meant. So this doesn't seem any
> clearer.
Well, in the EXTENDED section I took "too big" to refer back to the
immediately preceding paragraph:
- The TOAST code is triggered only when a row value to be stored in a
- table is wider than TOAST_TUPLE_THRESHOLD bytes (normally 2 kB). The
- TOAST code will compress and/or move field values out-of-line until
- the row value is shorter than TOAST_TUPLE_TARGET bytes (also
- normally 2 kB) or no more gains can be had.
I think I misunderstood the MAIN section precisely because it didn't
use the "too big" term at all, but instead said that it didn't allow
out-of-line storage except "as a last resort when there is no other
way to make the row small enough." If it's going to be conditioned on
the same limit, I would find it less confusing to stick with the same
terminology. That said, if you still find my wording confusing, it's
apparently not good enough. Suggestion?
>> It seems to me that MAIN might be a more useful option if it was
>> more aggressive about avoiding out-of-line storage; perhaps only if
>> the row doesn't fit by itself on a single page?
>
> Yeah I think we're on the same page there.
Cool.
> We've been talking about a number of ideas for making toast more
> flexible but there are clearly an infinite number of permutations
> and the trick will be figuring out how to present the useful ones
> without making things too complicated for the user to control.
So it would be premature to submit a patch for changing this behavior?
(I was thinking that if people could agree on this, it might be
something I could work in some evening, for some 8.5 commitfest.
If the OP is brave enough to use it, it might possibly solve the
problem.)
-Kevin
