Re: pgbench duration option
От | ITAGAKI Takahiro |
---|---|
Тема | Re: pgbench duration option |
Дата | |
Msg-id | 20080813121310.87AA.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: pgbench duration option (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: > > Here is a patch to add duration option (-T) to pgbench instead of > > number of transactions (-t). -t and -T are mutually exclusive. > > This seems like a fairly bad idea, because it introduces a > gettimeofday() call per transaction. On lots of (admittedly mostly > low-end) hardware, that will impose enough overhead to seriously > affect the results. Are there any evidence about the overhead of gettimeofday here? I think overhead of libpq API and pgbench itself (including generating SQLs) are far bigger than gettimeofday. > set up a timer signal handler that would set > a flag to shut down the test after the appropriate amount of time. There would be some porting problems in a timer singal hander. $ pgbench -n -S -c20 -T10 -M prepared transaction type: SELECT only scaling factor: 1 query mode: prepared number of clients: 20 number of transactions actually processed: 25978 in 10 s tps = 2589.707165 (including connections establishing) tps = 2707.804560 (excluding connections establishing) $ pgbench -n -S -c20 -t1250 -M prepared transaction type: SELECT only scaling factor: 1 query mode: prepared number of clients: 20 number of transactions per client: 1250 number of transactions actually processed: 25000/25000 tps = 2551.834131 (including connections establishing) tps = 2671.118531 (excluding connections establishing) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: