Re: Tracking last scan time - Mailing list pgsql-hackers

From Dave Page
Subject Re: Tracking last scan time
Date
Msg-id CA+OCxozy-DQLD7hOeT0FyimoCvp917TmsZ2Qp6QEbOn6AEeO4A@mail.gmail.com
Whole thread Raw
In response to Re: Tracking last scan time  (Andres Freund <andres@anarazel.de>)
Responses Re: Tracking last scan time  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: Allow logical replication to copy tables in binary format
Next
From: Ranier Vilela
Date:
Subject: re: PostgreSQL 15 GA release date