2009/4/18 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> 2009/4/11 Tom Lane <t...@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 >
transformHook.dif
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers