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
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

Reply via email to