Re: Fixed length data types issue - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Fixed length data types issue
Date
Msg-id EC43916E-2290-4882-B64F-DD81866386DC@nasby.net
Whole thread Raw
In response to Re: Fixed length data types issue  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Fixed length data types issue  (Markus Schaber <schabi@logix-tt.com>)
List pgsql-hackers
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)




pgsql-hackers by date:

Previous
From: "Marshall, Steve"
Date:
Subject: Re: - Proposal for repreparing prepared statements
Next
From: Jim Nasby
Date:
Subject: Re: Getting a move on for 8.2 beta