Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, sk(at)zsrv(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Date: 2018-11-08 05:52:53
Message-ID: CAA4eK1KzsbG2F095jR-m+JkgbJyePCBeXMk-RggiXxBXBwRTrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 4, 2018 at 6:37 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> wrote:
>
> On Sun, Nov 4, 2018 at 11:17 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>>
>> On Sat, Nov 03, 2018 at 03:56:14PM +0530, Amit Kapila wrote:
>> > Before trying out any solution or deciding which is better, I think we
>> > want to understand why the variability in results occurred only after
>> > your patch? Without the patch, it works just fine.
>>
>> Good point. We surely want to have a stable feature, which gets tested
>> without triggering random failures in the builfarm.
>
>
> Thanks for the review.
>
> This patch has changed the pg_stat_statements_reset() function from returning void
> to number statements that it reset.
>

What is the motivation of that change? It seems to be
backward-incompatible change. I am not telling we can't do it, but do
we have strong justification? One reason, I could see is to allow the
user to get the exact value of statements that got reset and maybe
that is more helpful as we have now additional parameters in the API,
but I am not sure if that is a good justification.

> The regression test contains pg_stat_statements_reset()
> as first query to reset any of the query stats that are already tracked to let the test to
> provide the proper results. But with this feature, if we test this regression test on an
> already running server, the first query result is varying and it leads to test failure.
>
> So to fix this problem, I added a wrapper function that masks the result of the
> pg_stat_statements_reset() function and just return as void, with this wrapper function
> used a first statement, the test is stable, as this function takes care of resetting already
> existing statements from the already running server.
>

Or you could change the query to something like (Select NULL from
pg_stat_statements_reset())

> With the above change, the regression test is stable. Comments?
>

In the comment message, you wrote: "Backward Compatible change, Now
pg_stat_statements_reset() function returns the number of statement
entries that are reset."

Do you want to say incompatible instead of compatible?

+ If no parameter is specified or specify everything as
<literal>NULL</literal>(invalid),
+ it will discard all statistics.
+ By default, this function can only be executed by superusers. Access may
+ be granted to others using <command>GRANT</command>.

I think it will look better if you can continue the "By default, ..."
line from where the previous line ends rather than starting a new
line.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-11-08 05:59:19 Re: Removing unneeded self joins
Previous Message Michael Paquier 2018-11-08 05:25:48 Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint