From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgbench duration option |
Date: | 2008-08-13 03:23:59 |
Message-ID: | 20080813121310.87AA.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-08-13 03:51:30 | Re: Transaction-controlled robustness for replication |
Previous Message | Tom Lane | 2008-08-13 03:22:16 | Re: SeqScan costs |