Re: Tracking last scan time

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Dave Page <dpage@pgadmin.org>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-08-31T18:56:29Z
Lists: 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



Commits

  1. Fix initialization of pg_stat_get_lastscan()

  2. pgstat: Track time of the last scan of a relation

  3. Have GetCurrentTransactionStopTimestamp() set xactStopTimestamp if unset