Hello Thomas,
>> After looking at it again, here is an update which ensure 64 bits on
>> epoch_shift computation.
>
> The code in pgbench 13 aggregates into buckets that begin on the
> boundaries of wall clock seconds, because it is triggered by changes
> in time_t. In the current patch, we aggregate data into buckets that
> begin on the boundaries of whole seconds since start_time. Those
> boundaries are not aligned with wall clock seconds, and yet we print
> out the times rounded to wall clock seconds.
Yes, I noticed this small changed, and did not feel it was an issue at the
time.
I thought of doing something like the format change your are suggesting.
However people would like it and it would need to be discussed, hence it
stayed that way… People have scripts to process log files and do not like
format changes, basically.
> Perhaps we should round the start time of the first aggregate down to
> the nearest wall clock second?
Yep, but that requires a common start point for all threads. Why not.
> That would mean that the first aggregate misses a part of a second (as
> it does in pgbench 13), but all later aggregates begin at the time we
> write in the log (as it does in pgbench 13). That is, if we log
> 1625115080 we mean "all results >= 1625115080.000000". It's a small
> detail, but it could be important for someone trying to correlate the
> log with other data. What do you think?
I think that you are right. The simplest way is to align on whole seconds,
which is easier than changing the format and have complaints about that,
or not align and have complaints about the timestamp being rounded.
Attached a v14 in that spirit.
--
Fabien.
