Re: Patch for 8.5, transformationHook

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch for 8.5, transformationHook
Дата
Msg-id 14267.1240057017@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch for 8.5, transformationHook  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Patch for 8.5, transformationHook  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Patch for 8.5, transformationHook  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2009/4/11 Tom Lane <tgl@sss.pgh.pa.us>:
>> No, I was complaining that a hook right there is useless and expensive.
>> transformExpr() is executed multiple times per query, potentially a very
>> large number of times per query; so even testing to see if a hook exists
>> is not a negligible cost.

> I did some tests based on pgbench.

The queries done by pgbench are completely trivial and do not stress
parser performance.  Even if they did (consider cases likw an IN with a
few thousand list items), the parser is normally not a bottleneck
compared to transaction overhead, network round trips, and pgbench
itself.

> I though about different position of hook, but only in this place the
> hook is useful (because expressions are recursive).

As I keep saying, a hook there is useless, at least by itself.  You
have no control over the grammar and no ability to modify what the
rest of the system understands.  The only application I can think of is
to fool with the transformation of FuncCall nodes, which you could do in
a much lower-overhead way by hooking into transformFuncCall.  Even that
seems pretty darn marginal for real-world problems.
        regards, tom lane


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [GENERAL] Performance of full outer join in 8.3
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: [rfc] unicode escapes for extended strings