Re: contrib/pg_stat_statements 1202

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/pg_stat_statements 1202
Date: 2008-12-09 08:20:46
Message-ID: Pine.GSO.4.64.0812090307490.13024@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 7 Dec 2008, Alex Hunsaker wrote:

> (dual core machine, --enable-debug, --enable-cassert build)
> pgbench -c 2 -T60 -n -f test.sql
>
> HEAD: tps = 9.674423
> PATCH: tps = 9.695784

Two general suggestions here, not specific to this patch:

While it's good to do most testing with debug and cassert turned on, you
shouldn't report performance results with those two flags enabled. What
if the patch has some large amount of overhead that only shows up when
compiled with debug or asserts on? You'd end up reporting a performance
loss that doesn't actually exist in a real build. Unfortunately, the only
way to get good performance results is to have a parallel build done with
those off, in addition to the debug/assert one used to catch bugs.

The above pgbench is executing less than 600 actual tests (60 seconds @
9.7TPS). That seems a bit short to me. If you sorted out the above and
run this again, it would be good to let pgbench run for a lot longer than
1 minute, to see if the results show some more significant difference.
With this few TPS, it would be nice to let that run for 30 minutes or more
if you can find some time to schedule that.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-12-09 10:00:29 Re: Sync Rep: First Thoughts on Code
Previous Message Fujii Masao 2008-12-09 08:15:05 Re: Sync Rep: First Thoughts on Code