From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch for 8.5, transformationHook |
Date: | 2009-04-18 12:16:57 |
Message-ID: | 14267.1240057017@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2009/4/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2009-04-18 12:29:05 | Re: [rfc] unicode escapes for extended strings |
Previous Message | Andrew Dunstan | 2009-04-18 12:07:23 | Re: [GENERAL] Performance of full outer join in 8.3 |