Re: [PATCH] backend: compare word-at-a-time in bcTruelen - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Date
Msg-id 20090626120304.GH20436@tamriel.snowman.net
Whole thread Raw
In response to Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Jeremy Kerr <jk@ozlabs.org>)
List pgsql-hackers
* Dimitri Fontaine (dfontaine@hi-media.com) wrote:
> Le 26 juin 09 à 05:20, Jeremy Kerr a écrit :
>>> Unfortunately, the cases with lots of padding spaces are probably
>>> much less probable than the cases with fewer.  It would be unpleasant
>>> for example if this patch resulted in a severe performance
>>> degradation for a "canonical" example of char(n) being used properly,
>>> such as char(2) for US state abbreviations.
>>
>> Yep, makes sense. The other consideration is stock-ticker symbols, I
>> assume they may also be stored in CHAR(small n) columns.
>
> Could this optimisation only kicks in when n is "big enough"?
> I'm don't know if this part of the code knows the typmod...

Is it just the size that matters, or is it when there are few spaces at
the end?  We do know the overall length, but I didn't see a definite
that if it's larger than X words, doing the by-word comparison is a win
regardless of how many actual spaces are at the end (apologies to Jeremy
if it's in his more detailed report, I havn't had a chance to look yet).
Thanks,
    Stpehen

pgsql-hackers by date:

Previous
From: Tsutomu Yamada
Date:
Subject: Proposal: More portable way to support 64bit platforms
Next
From: Jeremy Kerr
Date:
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen