Jan Wieck <janwieck@Yahoo.com> writes:
> Tom Lane wrote:
>> Now that you mention it, though, doesn't TOAST break heapam's assumption
>> that char(n) is fixed length? Seems like we'd better either remove that
>> assumption or mark char(n) nontoastable. Any opinions which is better?
> Is the saved overhead from assuming char(n) is fixed really
> that big that it's worth NOT to gain the TOAST advantages?
No, I don't think so. Instead of pulling out the code entirely,
however, we could extend the VARLENA_FIXED_SIZE macro to also check
whether attstorage = 'p' before reporting that a char(n) field is
fixed-size. Then someone who's really intent on keeping the old
behavior could hack the attribute entry to make it so.
I seem to recall that your original idea for TOAST included an ALTER
command to allow adjustment of attstorage settings, but that didn't
get done did it? Seems like it would be risky to change the setting
except on an empty table.
Not sure if any of this is worth keeping, or if we should just simplify
the code in heaptuple.c to get rid of the notion of "fixed size"
varlena attributes. It's certainly not going to be a mainstream case
anymore, so I question whether the check has any hope of saving more
cycles than it costs. Yet it seems a shame to wipe out this hack
entirely...
regards, tom lane
