Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: Andrei Zubkov <zubkov(at)moonset(dot)ru>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2023-01-25 15:46:40
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I've updated this patch for the current master. Also I have some
additional explanations..

On Wed, 2023-01-18 at 17:29 +0100, Tomas Vondra wrote:
> 1) I'm not sure why the patch is adding tests of permissions on the
> pg_stat_statements_reset function?

I've fixed that

> 2) If we want the second timestamp, shouldn't it also cover resets of
> the mean values, not just min/max?

I think that mean values are not a targets for auxiliary resets because
any sampling solution can easily calculate the mean values between
samples without a reset.

> 3) I don't understand why the patch is adding "IS NOT NULL AS t" to
> various places in the regression tests.

This change is necessary in the current version because the
pg_stat_statements_reset() function will return a timestamp of a reset,
needed for sampling solutions to detect resets, perfermed by someone

Andrei Zubkov

Attachment Content-Type Size
v15-0001-pg_stat_statements-Track-statement-entry-timestamp.patch text/x-patch 63.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Israel Barth Rubio 2023-01-25 15:46:55 Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Previous Message Aleksander Alekseev 2023-01-25 15:45:12 [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent