Re: pgbench duration option

Поиск
Список
Период
Сортировка
Искать
От
Greg Smith
Тема
Re: pgbench duration option
Дата
Msg-id
Pine.GSO.4.64.0808171555240.22068@westnet.com
Ответ на
Список
Дерево обсуждения
pgbench duration option ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: pgbench duration option Tom Lane <tgl@sss.pgh.pa.us>
Re: pgbench duration option ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: pgbench duration option Greg Smith <gsmith@gregsmith.com>
Re: pgbench duration option Tom Lane <tgl@sss.pgh.pa.us>
Re: pgbench duration option Greg Smith <gsmith@gregsmith.com>
Re: pgbench duration option Alvaro Herrera <alvherre@commandprompt.com>
Re: pgbench duration option Tom Lane <tgl@sss.pgh.pa.us>
Re: pgbench duration option ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: pgbench duration option Alvaro Herrera <alvherre@commandprompt.com>
[Review] pgbench duration option "Brendan Jurd" <direvus@gmail.com>
Re: [Review] pgbench duration option ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
On Tue, 12 Aug 2008, Tom Lane wrote:

> This seems like a fairly bad idea, because it introduces a
> gettimeofday() call per transaction.

There's already lots of paths through pgbench that introduce gettimeofday 
calls all over the place.  I fail to see how this is any different.

> If this were worth doing (which IMHO it isn't)

I think that switching the recommended practice for running pgbench to 
something time-based rather than transactions-based would increase the 
average quality of results people got considerably.  How many times do you 
see people posting numbers that worthless because the test ran for a 
trivial amount of time?  Seems like it happens a lot to me.  This patch 
was already on my todo list for 8.4 and I'm glad I don't have to write it 
myself now.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

В списке pgsql-hackers по дате отправления
От: Pavel Stehule
Дата:
От: Greg Smith
Дата:
Сообщение: Re: Overhauling GUCS
FAQ