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

From Andres Freund
Subject Re: Tracking last scan time
Date
Msg-id 20220906155325.an3xesq5o3fq36gt@awork3.anarazel.de
Whole thread Raw
In response to Re: Tracking last scan time  (Dave Page <dpage@pgadmin.org>)
Responses Re: Tracking last scan time
Re: Tracking last scan time
List pgsql-hackers
Hi,

On 2022-09-06 14:15:56 +0100, Dave Page wrote:
> Vik and I looked at this a little, and found that we actually don't have
> generally have GetCurrentTransactionStopTimestamp() at this point - a
> simple 'select * from pg_class' will result in 9 passes of this code, none
> of which have xactStopTimestamp != 0.

Huh, pgstat_report_stat() used GetCurrentTransactionStopTimestamp() has used
for a long time. Wonder when that was broken. Looks like it's set only when a
xid is assigned. We should fix this.


> After discussing it a little, we came to the conclusion that for the stated
> use case, xactStartTimestamp is actually accurate enough, provided that we
> only ever update it with a newer value. It would only likely be in extreme
> edge-cases where the difference between start and end transaction time
> would have any bearing on whether or not one might drop a table/index for
> lack of use.

I don't at all agree with this. Since we already use
GetCurrentTransactionStopTimestamp() in this path we should fix it.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Next
From: Nathan Bossart
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE