Re: [PATCH] backend: compare word-at-a-time in bcTruelen

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Дата
Msg-id 20090626120304.GH20436@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Dimitri Fontaine <dfontaine@hi-media.com>)
Ответы Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Jeremy Kerr <jk@ozlabs.org>)
Список 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 по дате отправления:

Предыдущее
От: Tsutomu Yamada
Дата:
Сообщение: Proposal: More portable way to support 64bit platforms
Следующее
От: Jeremy Kerr
Дата:
Сообщение: Re: [PATCH] backend: compare word-at-a-time in bcTruelen