On Wed, Mar 21, 2007 at 12:37:36PM -0400, Chris Browne wrote: > 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. > > At present, the 4 values are essentially advisory; columns get TOASTed > if the column permits EXTENDED storage, but that only occurs if the > size is greater than TOAST_TUPLE_THRESHOLD. > > If the new value was chosen, the column would *always* get stored as > TOAST. Rather than a hard and fast limit of 0, why not allow defining a size threshold? And while we're at it, how about a size threshold for when to try compressing, too?
> Presumably #1 or #2 could readily get into 8.3 as they're pretty easy; > #3 is a bit trickier, whilst #4 is probably not "8.3-fittable". > > Question: > > Which of these sounds preferable? 1 and 2 (variations on how to set the denominator) sound completely ugly. Trying to minimize wasted space in a toast table is great for a default, but exposing something like that to the users via any kind of setting seems way to obtuse. #3 (GUC for number of bytes) may not make sense for performance reasons, as Tom mentioned. I'm hoping that it would be easy to check either pg_class or pg_attribute to see if a table/column has non-standard toast/compression limits. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
