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
