On Tue, Dec 9, 2008 at 01:20, Greg Smith <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
