Re: New SQL counter statistics view (pg_stat_sql)

From: vinayak <Pokale_Vinayak_q3(at)lab(dot)ntt(dot)co(dot)jp>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New SQL counter statistics view (pg_stat_sql)
Date: 2017-01-20 04:31:43
Message-ID: d1f556f8-3920-cfaf-5b37-24d1259b9f9e@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2017/01/18 14:15, Haribabu Kommi wrote:
>
>
> On Sat, Jan 14, 2017 at 2:58 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com
> <mailto:dilipbalaut(at)gmail(dot)com>> wrote:
>
> On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar
> <dilipbalaut(at)gmail(dot)com <mailto:dilipbalaut(at)gmail(dot)com>> wrote:
> > +void
> > +pgstat_count_sqlstmt(const char *commandTag)
> > +{
> > + PgStat_SqlstmtEntry *htabent;
> > + bool found;
> > +
> > + if (!pgstat_track_sql)
> > + return
> >
> > Callers of pgstat_count_sqlstmt are always ensuring that
> > pgstat_track_sql is true, seems it's redundant here.
>
> I have done testing of the feature, it's mostly working as per the
> expectation.
>
>
> Thanks for the review and test.
>
> The use case for this view is to find out the number of different SQL
> statements
> that are getting executed successfully on an instance by the
> application/user.
>
> I have few comments/questions.
>
> --------
> If you execute the query with EXECUTE then commandTag will be EXECUTE
> that way we will not show the actual query type, I mean all the
> statements will get the common tag "EXECUTE".
>
> You can try this.
> PREPARE fooplan (int) AS INSERT INTO t VALUES($1);
> EXECUTE fooplan(1);
>
> ------
>
>
> Yes, that's correct. Currently the count is incremented based on the
> base command,
> because of this reason, the EXECUTE is increased, instead of the
> actual operation.
>
> + /* Destroy the SQL statement counter stats HashTable */
> + hash_destroy(pgstat_sql);
> +
> + /* Create SQL statement counter Stats HashTable */
>
> I think in the patch we have used mixed of "Stats HashTable" and
> "stats HashTable", I think better
> to be consistent throughout the patch. Check other similar instances.
>
> ----------------
>
>
> Corrected.
>
>
> @@ -1102,6 +1102,12 @@ exec_simple_query(const char *query_string)
>
> PortalDrop(portal, false);
>
> + /*
> + * Count SQL statement for pg_stat_sql view
> + */
> + if (pgstat_track_sql)
> + pgstat_count_sqlstmt(commandTag);
>
> We are only counting the successful SQL statement, Is that
> intentional?
>
>
> Yes, I thought of counting the successful SQL operations that changed the
> database over a period of time. I am not sure whether there will be many
> failure operations that can occur on an instance to be counted.
>
> ------
> I have noticed that pgstat_count_sqlstmt is called from
> exec_simple_query and exec_execute_message. Don't we want to track the
> statement executed from functions?
> -------
>
> The view is currently designed to count user/application initiated SQL
> statements,
> but not the internal SQL queries that are getting executed from
> functions and etc.
>
> >>+void
> >>+pgstat_count_sqlstmt(const char *commandTag)
> >>+{
> >>+ PgStat_SqlstmtEntry *htabent;
> >>+ bool found;
> >>+
> >>+ if (!pgstat_track_sql)
> >>+ return
> >
> >Callers of pgstat_count_sqlstmt are always ensuring that
> >pgstat_track_sql is true, seems it's redundant here.
>
> Removed the check in pgstat_count_sqlstmt statement and add it
> exec_execute_message
> function where the check is missed.
>
> Updated patch attached.
I have reviewed the patch. All the test cases works fine.

Regards,
Vinayak Pokale
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-01-20 05:24:55 Re: postgres_fdw bug in 9.6
Previous Message Etsuro Fujita 2017-01-20 03:41:12 Re: postgres_fdw bug in 9.6