On Tue, Dec 9, 2008 at 01:20, Greg Smith <gsmith@gregsmith.com> wrote:
> 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.
Right, which is part of the reason I noted it was a cassert build.
> 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.
Ok thats useful to know as well, thanks! (ill go re-run them)
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>