Re: [HACKERS] type cache for concat functions

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] type cache for concat functions
Дата
Msg-id CAFj8pRDg9hqxhZfbmoZkC=1Y3qr5kc4ZX2hNp8qgfn4_yLnoqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] type cache for concat functions  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список pgsql-hackers


2017-06-18 0:50 GMT+02:00 Dmitry Dolgov <9erthalion6@gmail.com>:
> On 20 May 2017 at 10:03, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Now concat is 2x times slower than || operator. With cached FmgrInfo for
> output function it will be only 5%.

Looks nice and does what's expected (what else one may need from a Saturday
evening). I just can mention that from what I see the previous version of
`concat` is slower the more arguments are getting involved, so looks like it
can be more than 2x.

Also, it was a little bit confusing to see that the function `concat` behaves
differently from operator `||` in terms of performance. When you're looking at
the code it's becoming obvious, but I couldn't find any mention about that in
the documentation.

There was few steps how to evaluate expressions more faster, but no step how to evaluate faster polymorphic "any" functions. A detecting of used argument type and looking to type cache are expensive. These functions was designed for string processing in error messages, and the performance was not too important. Now the concat function can be used often as replacement of || operator when you do migration from Oracle due similar behave. And the performance is more interesting now.

I think so can be interesting to allow some activity in analyzing/planning time and prexec stage to user function developers. Some is possible via planning time hooks, but for controlling few functions it is not user friendly - and there are no space for data from this stages.

Regards

Pavel


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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Decimal64 and Decimal128
Следующее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] logical replication - still unstable after all thesemonths