Re: Patch for 8.5, transformationHook
От | Pavel Stehule |
---|---|
Тема | Re: Patch for 8.5, transformationHook |
Дата | |
Msg-id | 162867790904200545x5078818dke7692e7bb67f3160@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch for 8.5, transformationHook (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch for 8.5, transformationHook
|
Список | pgsql-hackers |
2009/4/18 Tom Lane <tgl@sss.pgh.pa.us>: > 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. > Hello I am sending modified patch - it hooking parser via transformFuncCall regards Pavel Stehule > regards, tom lane >
Вложения
В списке pgsql-hackers по дате отправления: