2013/1/4 Tom Lane <tgl@sss.pgh.pa.us>:
> "Dong Ye" <yed@vmware.com> writes:
>> I did three back-to-back runs using the same settings as in
>> http://archives.postgresql.org/pgsql-performance/2012-11/msg00007.php
>> Except:
>> - use no prepared statement
>> - use 40 db connections
>> - build source from postgresql.git on the server box using: REL9_1_7,
>> REL9_2_2, REL9_2_2 + this patch
>
>> NOTPM results:
>> REL9_1_7: 46512.66
>> REL9_2_2: 42828.66
>> REL9_2_2 + this patch: 46973.70
>
> Thanks! I think this is probably sufficient evidence to conclude that
> we should apply this patch, at least in HEAD. Whatever Peter is seeing
> must be some other issue, which we can address whenever we understand
> what it is.
>
> Next question is what people think about back-patching into 9.2 so as
> to eliminate the performance regression vs 9.1. I believe this would
> be safe (although some care would have to be taken to put the added
> boolean fields into places where they'd not result in an ABI break).
> However it may not be worth the risk. The 40% slowdown seen with
> Pavel's example seems to me to be an extreme corner case --- Dong's
> result of 8% slowdown is probably more realistic for normal uses
> of SPI_execute. Might be better to just live with it in 9.2.
> Thoughts?
I am for back-patching - I agree with you so my example is corner
case, and cannot be worse example - but performance regression about
5-10% can be confusing for users - because they can searching
regression in their application.
Regards
Pavel Stehule
>
> regards, tom lane
