Re: Fixed length data types issue

On Sep 11, 2006, at 1:57 PM, Gregory Stark wrote:
> Tom Lane <tgl@sss.pgh.pa.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@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)