Re: Tracking last scan time

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Tracking last scan time
Дата
Msg-id CA+OCxozy-DQLD7hOeT0FyimoCvp917TmsZ2Qp6QEbOn6AEeO4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tracking last scan time  (Andres Freund <andres@anarazel.de>)
Ответы Re: Tracking last scan time  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hi

On Fri, 30 Sept 2022 at 18:58, Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2022-09-30 17:58:31 +0200, Vik Fearing wrote:
> On 9/7/22 12:03, Dave Page wrote:
> > Here's a v4 patch. This reverts to using
> > GetCurrentTransactionStopTimestamp() for the last_scan times, and will
> > set xactStopTimestamp the first time GetCurrentTransactionStopTimestamp()
> > is called, thus avoiding multiple gettimeofday() calls.
> > SetCurrentTransactionStopTimestamp() is removed, as is use
> > of xactStopTimestamp (except when resetting it to 0).
>
> This patch looks good to me and has much saner behavior than what it
> replaces.

I agree. However, it seems like a significant enough behavioural change that
I'd rather commit it as a separate patch.  I agree with Vik's judgement that
the patch otherwise is otherwise ready. Happy to do that split myself, or you
can do it...

Thanks. It's just the changes in xact.c, so it doesn't seem like it would cause you any more work either way, in which case, I'll leave it to you :-)

FYI, the OID I chose was simply the closest single value to those used for the other related functions (e.g. pg_stat_get_numscans). Seemed like a good way to use up one more random unused value, but I don't care if it gets changed to the 8000+ range.

--

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

Предыдущее
От: Melih Mutlu
Дата:
Сообщение: Re: Allow logical replication to copy tables in binary format
Следующее
От: Ranier Vilela
Дата:
Сообщение: re: PostgreSQL 15 GA release date