Re: pgbench logging broken by time logic changes

At Thu, 17 Jun 2021 12:23:42 +0900, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote in
> On Wed, 16 Jun 2021 21:11:41 +0200 (CEST)
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> > I cannot say that I'm thrilled by having multiple tv stuff back in several
> > place. I can be okay with one, though. What about the attached? Does it
> > make sense?

+1 The patch rounds down sd->start_time from ms to s but it seems to
me a degradation.

> At first, I also thought of fixing pg_time_now() to use gettimeofday() instead
> of INSTR_TIME_SET_CURRENT, but I noticed that using INSTR_TIME_SET_CURRENT is
> proper to measure time interval. I mean, this macro uses
> lock_gettime(CLOCK_MONOTONIC, ) if avilable, which give reliable interval
> timing even in the face of changes to the system clock due to NTP.

If I understand the op correctly, the problem here is the time values
in pgbench log file are based on a bogus epoch. If it's the only issue
here and and if we just want to show the time based on the unix epoch
time, just recording the difference would work as I scketched in the
attached. (Precisely theepoch would move if we set the system clock
but I don't think that matters:p)

> By the way, there is another advantage of using clock_gettime(). That is, this
> returns precise results in nanoseconds. However, we can not benefit from it because
> pg_time_now() converts the value to uint64 by using INSTR_TIME_GET_MICROSEC. So,
> if we would like more precious statistics in pgbench, it might be better to use
> INSTR_TIME_GET_MICROSEC instead of pg_time_now in other places.

I'm not sure we have transaction lasts for very short time that
nanoseconds matters.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center