Re: Tracking last scan time
От | Andres Freund |
---|---|
Тема | Re: Tracking last scan time |
Дата | |
Msg-id | 20220831185629.mrr2jlwjubsy2pvi@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Tracking last scan time (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Tracking last scan time
Re: Tracking last scan time |
Список | pgsql-hackers |
Hi, On 2022-08-31 19:52:49 +0200, Matthias van de Meent wrote: > As for having a lower granularity and preventing the > one-syscall-per-Relation issue, can't we reuse the query_start or > state_change timestamps that appear in pg_stat_activity (potentially > updated immediately before this stat flush), or some other per-backend > timestamp that is already maintained and considered accurate enough > for this use? The problem is that it won't change at all for a query that runs for a week - and we'll report the timestamp from a week ago when it finally ends. But given this is done when stats are flushed, which only happens after the transaction ended, we can just use GetCurrentTransactionStopTimestamp() - if we got to flushing the transaction stats we'll already have computed that. > tabentry->numscans += lstats->t_counts.t_numscans; > + if (pgstat_track_scans && lstats->t_counts.t_numscans) > + tabentry->lastscan = GetCurrentTimestamp(); Besides replacing GetCurrentTimestamp() with GetCurrentTransactionStopTimestamp(), this should then also check if tabentry->lastscan is already newer than the new timestamp. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: