From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch for 8.5, transformationHook |
Date: | 2009-07-26 03:44:59 |
Message-ID: | 603c8f070907252044x228729a4wd90a9d95425a0ab6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
> Hello
>
> 2009/7/25 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
>>> 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.
>>>>
>>>
>>> I am sending modified patch - it hooking parser via transformFuncCall
>>
>> I am reviewing this patch. It seems to me upon rereading the thread
>> that the objections Tom and Peter had to inserting a hook into
>> transformExpr() mostly still apply to a hook in transformFuncCall():
>> namely, that there's no proof that putting a hook here is actually
>> useful. I think we should apply the same criteria to this that we
>> have to some other patches that have been rejected (like the
>> extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely,
>> requiring that the extension mechanism be submitted together with at
>> least two examples of how it can be used to interesting and useful
>> things, bundled as one or more contrib modules.
>
> I have in my plan add to contrib JSON support similar to Bauman design:
>
> http://www.mysqludf.org/lib_mysqludf_json/index.php
>
> It's will be sample of "smart" functions. Because this need more then
> less work I am waiting on commit.
>
> Other simple intrduction contrib module should be real Oracle decode
> function - I sent source code some time ago. But this code needs some
> modification. I should send this code if you need it.
Sure, post it and let's discuss.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-07-26 04:17:49 | Re: mixed, named notation support |
Previous Message | Robert Haas | 2009-07-26 03:44:24 | Re: SE-PostgreSQL Specifications |