Re: pgbench progress with timestamp - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench progress with timestamp
Date
Msg-id alpine.DEB.2.10.1509080815390.17831@sto
Whole thread Raw
In response to Re: pgbench progress with timestamp  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: pgbench progress with timestamp  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
>> 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.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Horizontal scalability/sharding
Next
From: Michael Paquier
Date:
Subject: Re: Use pg_rewind when target timeline was switched