Re: Patch for 8.5, transformationHook
От | Pavel Stehule |
---|---|
Тема | Re: Patch for 8.5, transformationHook |
Дата | |
Msg-id | 162867790904180426j42a51416n6609b03ec42f8526@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch for 8.5, transformationHook (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch for 8.5, transformationHook
|
Список | 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 по дате отправления: