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

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Дата
Msg-id e51f66da0906180514i1de3b6cdvc04e5134d416c200@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 6/18/09, Simon Riggs <simon@2ndquadrant.com> wrote:
>  On Tue, 2009-06-16 at 10:23 -0400, Tom Lane wrote:
>  > Speaking of which, what about some performance numbers?  Like Heikki,
>  > I'm quite suspicious of whether there is any real-world gain to be had
>  > from this approach.
>
>
> It has been "lore" for some time that VARCHAR is cheaper than
>  VARCHAR(n), so I'm looking forward to this improvement as a real-world
>  gain. (If done right).
>
>  I've looked at the code and the thing that bothers me is that I can't
>  see where or why bcTruelen would be called more often for VARCHAR(n)
>  than it would be for VARCHAR, on a Select/Sort only workload.

I'd guess plain VARCHAR simply does not have blanks at the end,
so Truelen is cheap.

>  Are we tuning the right thing? Is there some code we can completely
>  avoid?
>
>  If not, does this mean it is a generic effect? Does this imply that
>  NUMERIC(n) is somehow worse than NUMERIC? etc..

Probably not.  For numeric the (n) seems to be only checked input time.

-- 
marko


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCH] backend: compare word-at-a-time in bcTruelen