Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: Andrei Zubkov <zubkov(at)moonset(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2023-03-16 11:02:51
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi Michael,

Thank you for your attention.

On Thu, 2023-03-16 at 16:13 +0900, Michael Paquier wrote:
> +/* First we have to remove them from the extension */
> +ALTER EXTENSION pg_stat_statements DROP VIEW pg_stat_statements;
> pg_stat_statements(boolean);
> +  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.

Agreed. I've done it as it was in previous versions. But I'm sure those
are unnecessary.

> 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..
Splitting this commit seems reasonable to me.

New version is attached.

Attachment Content-Type Size
v20-0001-pg_stat_statements-tests-Add-NOT-NULL-checking-of-pg.patch text/x-patch 50.2 KB
v20-0002-pg_stat_statements-Track-statement-entry-timestamp.patch text/x-patch 38.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuya Watari 2023-03-16 11:45:28 Re: Making empty Bitmapsets always be NULL
Previous Message Amit Kapila 2023-03-16 10:56:35 Re: logical decoding and replication of sequences, take 2