Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date
Msg-id 20210323070325.n6hgjonavdwlm5al@nol
Whole thread Raw
In response to Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Andrei Zubkov <zubkov@moonset.ru>)
Responses Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
List pgsql-hackers
On Tue, Mar 23, 2021 at 09:50:16AM +0300, Andrei Zubkov wrote:
> 
> By the way right now in my workload tracing tool pg_profile I have to
> reset pg_stat_statements on every sample (wich is about 30-60 minutes)
> to make sure that all workload between samples is captured. This causes
> much more overhead. Introduced first_seen column can eliminate the need
> of resets.

Note that you could also detect entries for which some counters decreased (e.g.
the execution count), and in that case only use the current values.  It should
give the exact same results as what you will get with the first_seen column,
except of course if some entry is almost never used and is suddenly used a lot
after an explicit reset or an eviction and only until you perform your
snapshot.  I'm not sure that it's a very likely scenario though.

FTR that's how powa currently deals with reset/eviction.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies
Next
From: Fujii Masao
Date:
Subject: Re: About to add WAL write/fsync statistics to pg_stat_wal view