Re: Patch for 8.5, transformationHook - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Patch for 8.5, transformationHook
Date
Msg-id 162867790904180426j42a51416n6609b03ec42f8526@mail.gmail.com
Whole thread Raw
In response to Re: Patch for 8.5, transformationHook  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch for 8.5, transformationHook
List pgsql-hackers
Hello

2009/4/11 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2009/4/11 Tom Lane <tgl@sss.pgh.pa.us>:
>>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>>> I am sending small patch, that allows hooking transformation stage of parser.
>>>
>>> Isn't this the exact same patch we rejected several months ago?
>
>> What I remember, You had some objections about different behave before
>> and after loading an library.
>
> 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.  And I have not seen anything I regard as a
> convincing demonstration of use-case that can't be handled as well or
> better in some other way.
>
>                        regards, tom lane
>

I did some tests based on pgbench.

The test base was initialised with scaling factor 10. I tested high
transaction number with single client. Result is not clean, but
doesn't show significant slowness for patched parser. In both cases
pbbench and postresql was installed on single computer.

First I tested on 4years old notebook prestigio nobile 156 (Pentium M, 1.6).

I tested pgbench (-t 100000) with/without switch -S

without patch   6950+/-13 (-S)   660 +/- 11
patched           6879+/-30         672 +/- 21
--------------------------------------------------
diff                      -1.02%           +1.79%

Next test I did on Dell 830 Core(TM)2 Duo 2.4

withhout patch 9253+/-47 (-S)    209 +/- 4
patched          9299+/-14          214+/- 1
---------------------------------------------------
diff                  +0.49%              +2.33%

Result: The most worst case - pgbench -S -t100000 is 1% slower then
unpatched code (on older computer). With some more similar to normal
traffic, the patched code was 2% faster.

I don't know why patched code should be faster - but this is result
from pgbench - on linux fedora 10, Intel, without GUI

I though about different position of hook, but only in this place the
hook is useful (because expressions are recursive). Elsewhere the hook
hasn't sense :(. So transformationHook doesn't do significant
slowness.

Other possibility is an callback, or some, but I dislike it.

Regards
Pavel Stehule


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [GENERAL] Performance of full outer join in 8.3
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE