Re: Fixed length data types issue

On Sep 11, 2006, at 1:57 PM, Gregory Stark wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think its's more important to pick bitpatterns that reduce the
>> number of
>> cases heap_deform_tuple has to think about while decoding the
>> length of a
>> field --- every "if" in that inner loop is expensive.
>
> I'll have to spend a few hours tomorrow becoming one with that
> section of
> code. I looked at it already and was surprised at how short it was
> already so
> I can understand what you mean.

I'm guessing this won't change the design, but I'll throw it out
anyway. I'd love to have the ability to control toasting thresholds
manually. This could result in a lot of speed improvements in cases
where a varlena field isn't frequently accessed and will be fairly
large, yet not large enough to normally trigger toasting. An address
field would be a good example. Being able to force a field to be
toasted before it normally would could drastically improve tuple
density without requiring the developer to use a 'side table' to
store the data.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)