2013/1/4 Tom Lane <t...@sss.pgh.pa.us>: > "Dong Ye" <y...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
