Re: contrib/pg_stat_statements 1202
От | Greg Smith |
---|---|
Тема | Re: contrib/pg_stat_statements 1202 |
Дата | |
Msg-id | Pine.GSO.4.64.0812090307490.13024@westnet.com обсуждение исходный текст |
Ответ на | Re: contrib/pg_stat_statements 1202 ("Alex Hunsaker" <badalex@gmail.com>) |
Ответы |
Re: contrib/pg_stat_statements 1202
|
Список | 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@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: