Re: Misuse of TimestampDifference() in the autoprewarm feature of pg_prewarm
От | Tom Lane |
---|---|
Тема | Re: Misuse of TimestampDifference() in the autoprewarm feature of pg_prewarm |
Дата | |
Msg-id | 1996862.1604953516@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Misuse of TimestampDifference() in the autoprewarm feature of pg_prewarm (Alexey Kondratov <a.kondratov@postgrespro.ru>) |
Ответы |
Re: Misuse of TimestampDifference() in the autoprewarm feature of pg_prewarm
|
Список | pgsql-hackers |
Alexey Kondratov <a.kondratov@postgrespro.ru> writes: > On 2020-11-09 21:53, Tom Lane wrote: >> 0002 seems like a pretty clear bug fix, though I wonder if this is exactly >> what we want to do going forward. It seems like a very large fraction of >> the callers of TimestampDifference would like to have the value in msec, >> which means we're doing a whole lot of expensive and error-prone >> arithmetic to break down the difference to sec/usec and then put it >> back together again. Let's get rid of that by inventing, say >> TimestampDifferenceMilliseconds(...). > Yeah, I get into this problem after a bug in another extension — > pg_wait_sampling. I have attached 0002, which implements > TimestampDifferenceMilliseconds(), so 0003 just uses this new function > to solve the initial issues. If it looks good to you, then we can switch > all similar callers to it. Yeah, let's move forward with that --- in fact, I'm inclined to back-patch it. (Not till the current release cycle is done, though. I don't find this important enough to justify a last-moment patch.) BTW, I wonder if we shouldn't make TimestampDifferenceMilliseconds round any fractional millisecond up rather than down. Rounding down seems to create a hazard of uselessly waking just before the delay is completed. Better to wake just after. I still think your 0001 is fishy, but don't have time today to stare at it more closely. regards, tom lane
В списке pgsql-hackers по дате отправления: