Greg Stark <st...@enterprisedb.com> wrote: > On Thu, Jun 11, 2009 at 5:12 PM, Kevin > Grittner<kevin.gritt...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
