On Tue, Dec 10, 2013 at 10:59 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Tue, Dec 10, 2013 at 6:56 AM, Nigel Heron <nhe...@querymetrics.com> wrote: >> On Sat, Dec 7, 2013 at 1:17 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> >>> Could you share the performance numbers? I'm really concerned about >>> the performance overhead caused by this patch. >>> >> >> I've tried pgbench in select mode with small data sets to avoid disk >> io and didn't see any difference. That was on my old core2duo laptop >> though .. I'll have to retry it on some server class multi core >> hardware. > > When I ran pgbench -i -s 100 in four parallel, I saw the performance > difference > between the master and the patched one. I ran the following commands. > > psql -c "checkpoint" > for i in $(seq 1 4); do time pgbench -i -s100 -q db$i & done > > The results are: > > * Master > 10000000 of 10000000 tuples (100%) done (elapsed 13.91 s, remaining 0.00 s). > 10000000 of 10000000 tuples (100%) done (elapsed 14.03 s, remaining 0.00 s). > 10000000 of 10000000 tuples (100%) done (elapsed 14.01 s, remaining 0.00 s). > 10000000 of 10000000 tuples (100%) done (elapsed 14.13 s, remaining 0.00 s). > > It took almost 14.0 seconds to store 10000000 tuples. > > * Patched > 10000000 of 10000000 tuples (100%) done (elapsed 14.90 s, remaining 0.00 s). > 10000000 of 10000000 tuples (100%) done (elapsed 15.05 s, remaining 0.00 s). > 10000000 of 10000000 tuples (100%) done (elapsed 15.42 s, remaining 0.00 s). > 10000000 of 10000000 tuples (100%) done (elapsed 15.70 s, remaining 0.00 s). > > It took almost 15.0 seconds to store 10000000 tuples. >-- Regards,
Atri l'apprenant > Thus, I'm afraid that enabling network statistics would cause serious > performance > degradation. Thought? Hmm, I think I did not push it this high. The performance numbers here are cause of worry. Another point I may mention here is that if we can isolate a few points of performance degradation and work on them because I still feel that the entire patch itself does not cause a serious lapse, rather, a few points may. However, the above numbers bring up the original concerns for the performance voiced. I guess I was testing on too low number of clients for the gap to show up significantly. Regards, Atri -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
