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. Thus, I'm afraid that enabling network statistics would cause serious performance degradation. Thought? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers