From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Tracking last scan time |
Date: | 2022-09-06 15:53:25 |
Message-ID: | 20220906155325.an3xesq5o3fq36gt@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-09-06 15:54:32 | Re: predefined role(s) for VACUUM and ANALYZE |
Previous Message | Robert Haas | 2022-09-06 15:24:18 | Re: predefined role(s) for VACUUM and ANALYZE |