On Sep 11, 2006, at 1:57 PM, Gregory Stark wrote:
Tom Lane <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
