Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
От | Andres Freund |
---|---|
Тема | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Дата | |
Msg-id | 20220617180247.m62yfxy4d4pq4xvl@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On 2022-06-17 13:43:49 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I should have been more precise - what I meant was a timeout.c API that allows > > the caller to pass in "now", which in this case we'd get from > > GetCurrentTransactionStopTimestamp(), which would avoid the additional > > timestamp computation. > > I don't care for that one bit: it makes the accuracy of all timeouts > dependent on how careful that caller is to provide an up-to-date "now". I don't think it'd necessarily have to influence the accuracy of all timeouts - but I've not looked at timeout.c much before. From what I understand we use 'now' for two things: First, to set ->start_time in enable_timeout() and second to schedule the alarm in schedule_alarm(). An inaccurate start_time won't cause problems for other timers afaics and it looks to me that it wouldn't be too hard to only require an accurate 'now' if the new timeout is nearest_timeout and now + nearest_timeout < signal_due_at? It's probably to complicated to tinker with now tho. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: