Re: Feature improvement for pg_stat_statements - Mailing list pgsql-hackers

From btnakamichin
Subject Re: Feature improvement for pg_stat_statements
Date
Msg-id e703d362d709c511586d7bb54ec944e7@oss.nttdata.com
Whole thread Raw
In response to Re: Feature improvement for pg_stat_statements  (Andres Freund <andres@anarazel.de>)
Responses Re: Feature improvement for pg_stat_statements
List pgsql-hackers
2020-09-22 04:58 に Andres Freund さんは書きました:
> Hi,
> 
> On 2020-09-18 17:55:12 +0900, btnakamichin wrote:
>> I’m thinking of adding adding a function called
>> pg_stat_statements_reset_time() that returns the last timestamp when
>> executed pg_stat_statements_reset(). pg_stat_statements can reset each 
>> SQL
>> statement. We can record each sql reset timing timestamp but I don’t 
>> feel
>> the need. This time, I’m thinking of updating the reset timestamp only 
>> when
>> all stats were reset.
> 
> What exactly do you mean by "can reset each SQL statement"? I don't
> really see what alternative you're analyzing?
> 
> It does make sense to me to have a function returning the time of the
> last reset.
> 
> Greetings,
> 
> Andres Freund

I’m Sorry, I forgot to include pgsql_hackers in the cc, so I resend it 
and attach the patch.
Thank you, I appreciate your comment.

I am unfamiliar with this function. I’m sorry if my interpretation is 
mistaken.

> What exactly do you mean by "can reset each SQL statement"? I don't
> really see what alternative you're analyzing?

pg_stat_statements_reset discards statistics gathered so far by 
pg_stat_statements corresponding to the specified userid, dbid and 
queryid.

If no parameter is specified or all the specified parameters are 
0(invalid), it will discard all statistics.

I think that it is important to record timestamp discarding all 
statistics so I’d like to add a function for only all stats were reset.

The following is an example of this feature.
postgres=# select * from pg_stat_statements_reset_time();
  pg_stat_statements_reset_time
-------------------------------
  2020-09-24 13:36:44.87005+09
(1 row)

Best regards,

Naoki Nakamichi
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: problem with RETURNING and update row movement
Next
From: Michael Paquier
Date:
Subject: Re: Missing TOAST table for pg_class