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  ("Alex Hunsaker" <badalex@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Fujii Masao"
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code