Re: [HACKERS] Fixing pgbench's logging of transaction timestamps

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] Fixing pgbench's logging of transaction timestamps
Дата
Msg-id alpine.DEB.2.20.1701011128380.15074@lancre
обсуждение исходный текст
Ответ на [HACKERS] Fixing pgbench's logging of transaction timestamps  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Fixing pgbench's logging of transaction timestamps  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hello and happy new year,

> -l [...]

My 0.02€:

> There are at least three ways we could fix it:
>
> 1. Switch over to printing the timestamp in the form of elapsed seconds 
> since the pgbench run start, [...] About the only reason I can see for 
> liking the current definition is that it makes it possible to correlate 
> the pgbench log with external events, and I'm not sure whether that's 
> especially useful.

I have found that the ability to correlate different logs, esp. pgbench 
and postgres, is "sometimes" useful.

> 2. Have pgbench save both the INSTR_TIME_SET_CURRENT() and 
> gettimeofday() results for the run start instant. However, it's got a 
> nasty problem [...]

I'm not sure how wide the problem would be. I would not expect the 
correlation to be perfect, as there are various protocol/client overheads 
here and there anyway.

> 3. Forget about using the instr_time result and just have doLog() execute
> gettimeofday() to obtain the timestamp to print.  This is kind of
> conceptually ugly, but realistically the added overhead is probably
> insignificant.  A larger objection might be that on Windows, the result
> of gettimeofday() isn't very high precision ... but it'd still be a huge
> improvement over the non-answer you get now.

Yep.

> I'm inclined to think that #2 isn't a very good choice; it appears to
> preserve the current behavior but really doesn't.  So we should either
> change the behavior as in #1 or expend an extra system call as in #3.
> Preferences?

Marginal preference for #3 for KIS? Otherwise any three options seems 
better than the current status.

-- 
Fabien.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables