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

From Michael Paquier
Subject Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date
Msg-id ZBLBijHGpy+Vse/D@paquier.xyz
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  (Andrei Zubkov <zubkov@moonset.ru>)
Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Andrei Zubkov <zubkov@moonset.ru>)
List pgsql-hackers
On Sat, Mar 11, 2023 at 02:49:50PM +0300, Andrei Zubkov wrote:
> Hi,
>
> I've done a rebase of a patch to the current master.

+/* First we have to remove them from the extension */
+ALTER EXTENSION pg_stat_statements DROP VIEW pg_stat_statements;
+ALTER EXTENSION pg_stat_statements DROP FUNCTION pg_stat_statements(boolean);
+ALTER EXTENSION pg_stat_statements DROP FUNCTION
+  pg_stat_statements_reset(Oid, Oid, bigint);

The upgrade script of an extension is launched by the backend in the
context of an extension, so these three queries should not be needed,
as far as I recall.

-SELECT pg_stat_statements_reset();
- pg_stat_statements_reset
---------------------------
-
+SELECT pg_stat_statements_reset() IS NOT NULL AS t;
+ t
+---
+ t
 (1 row)

Wouldn't it be better to do this kind of refactoring in its own patch
to make the follow-up changes more readable?  This function is changed
to return a timestamp rather than void, but IS NOT NULL applied on the
existing queries would also return true.  This would clean up quite a
few diffs in the main patch..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Split index and table statistics into different types of stats
Next
From: Michael Paquier
Date:
Subject: Re: Combine pg_walinspect till_end_of_wal functions with others