Re: pgbench logging broken by time logic changes
От | Fabien COELHO |
---|---|
Тема | Re: pgbench logging broken by time logic changes |
Дата | |
Msg-id | alpine.DEB.2.22.394.2106170901100.2693553@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench logging broken by time logic changes (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
Hello, >>> 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. Yes, please we should not use time. >> 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. It is not "bogus", but is not necessary epoch depending on the underlying function called behind by INSTR_TIME macros, and people are entitled to expect epoch for log correlations. > 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) I do like the approach. I'm hesitant to promote it for fixing the beta, but the code impact is small enough, so I'd say yes. Maybe there is a similar issue with progress which should probably use the same approach. I think that aligning the implementations can wait for pg15. The patch as white space issues. Attached an updated version which fixes that, adds comments and simplify the code a little bit. > I'm not sure we have transaction lasts for very short time that > nanoseconds matters. Indeed. -- Fabien.
Вложения
В списке pgsql-hackers по дате отправления: