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 jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
