Skip site navigation (1) Skip section navigation (2)

Re: Patch for 8.5, transformationHook

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch for 8.5, transformationHook
Date: 2009-04-20 12:45:57
Message-ID: 162867790904200545x5078818dke7692e7bb67f3160@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2009/4/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.
>

Hello

I am sending modified patch - it hooking parser via transformFuncCall

regards
Pavel Stehule


>                        regards, tom lane
>

Attachment: transformHook.dif
Description: application/octet-stream (1.6 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-04-20 14:14:01
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Previous:From: Andreas PflugDate: 2009-04-20 11:10:55
Subject: Re: Warm Standby restore_command documentation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group