From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unfortunate choice of short switch name in pgbench |
Date: | 2014-02-26 09:04:36 |
Message-ID: | 530DAE24.7030409@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/25/2014 11:32 PM, Tom Lane wrote:
> Meh. A progress-reporting feature has use when the tool is working
> towards completion of a clearly defined task. In the case of pgbench,
> if you told it to run for -T 60 seconds rather than -T 10 seconds,
> that's probably because you don't trust a 10-second average to be
> sufficiently reproducible. So I'm not real sure that reporting averages
> over shorter intervals is all that useful; especially not if it takes
> cycles out of pgbench, which itself is often a bottleneck.
It's not useful when doing rigorous benchmarking to publish results, but
in quick testing of various hacks during development, getting 10-second
averages is very useful. You quickly see how stable the short averages
are, and you can just hit CTRL-C when you've seen enough, without having
to decide the suitable test length before hand.
It's also useful to see how checkpoints or autovacuum affects the
transaction rate.
That said, no objection to removing the -P shorthand.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2014-02-26 09:16:02 | Re: Custom Scan APIs (Re: Custom Plan node) |
Previous Message | Sergey Burladyan | 2014-02-26 08:58:57 | Re: BUG #9223: plperlu result memory leak |