From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench progress with timestamp |
Date: | 2015-09-08 16:03:46 |
Message-ID: | CAMkU=1woC1WGjr0DD3RogQc_A_2Aef-Yqu-9gGg7JSsK-sPu-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 7, 2015 at 11:25 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> Use milliseconds for consistency with the '%n' log_prefix patch currently
>>> submitted by Tomas Vondra in the CF.
>>>
>>> sh> ./pgbench -P 1 -N -T 100 -c 2
>>> starting vacuum...end.
>>> progress: 1.0 s, 546.0 tps, lat 3.619 ms stddev 4.426
>>> progress: 2.0 s, 575.0 tps, lat 3.480 ms stddev 1.705
>>>
>>> sh> ./pgbench -P 1 --progress-timestamp -N -T 100 -c 2
>>> starting vacuum...end.
>>> progress: 1440328800.064 s, 549.0 tps, lat 3.602 ms stddev 1.698
>>> progress: 1440328801.064 s, 570.0 tps, lat 3.501 ms stddev 1.704
>>>
>>
>> I like the idea of the timestamp. But could just always print both the
>> timestamp and the elapsed time, rather than adding another switch to
>> decide
>> between them?
>>
>
> I agree that an option for this purpose is on the heavy side.
>
> I'm not sure how fine it would be, though: progress lines can already be a
> little bit long (under -R & -L) and I do not like wide terminal. Also, I
> see --progress as a "user friendly" easy to read feature to know how things
> are going during a run. A timestamp does not fall into this category: it is
> pretty ugly and unreadable, so it is really out of necessity that I'm
> resorting to that.
>
> So I would rather keep the option because of the inelegance of having
> timestamps printed.
OK.
In the sgml, second should be plural in 'intead of the number of second
since the'. And 'intead' should be 'instead'.
Also, in the usage message, I think the key piece of this is that it is
Unix-epoch, not that it is ms resolution:
--progress-timestamp use a ms timestamp for progress
Maybe
--progress-timestamp use a Unix-like epoch timestamp for progress
reporting
but that is getting pretty long.
Other than that, I think it looks good.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2015-09-08 16:23:03 | Re: Memory Context Info dump |
Previous Message | Alvaro Herrera | 2015-09-08 16:00:38 | Re: Allow a per-tablespace effective_io_concurrency setting |