Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-04-06 Thread Haribabu Kommi
On Thu, Apr 6, 2017 at 5:17 AM, Andres Freund wrote: > Hi, > > > I'm somewhat inclined to think that this really would be better done in > an extension like pg_stat_statements. > Thanks for the review. > > > +} > > + > > +/* > > + * Count SQL statement for pg_stat_sql view > > + */ > > +void

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-04-05 Thread Andres Freund
Hi, I'm somewhat inclined to think that this really would be better done in an extension like pg_stat_statements. On 2017-03-08 14:39:23 +1100, Haribabu Kommi wrote: > On Wed, Feb 1, 2017 at 3:13 PM, Michael Paquier > + > + track_sql (boolean) > + > + track_sql configura

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-03-07 Thread Haribabu Kommi
On Wed, Feb 1, 2017 at 3:13 PM, Michael Paquier wrote: > On Fri, Jan 27, 2017 at 10:26 AM, Haribabu Kommi > wrote: > > Thanks for the review. > > Let's wait for the committer's opinion. > > I have moved this patch to CF 2017-03 to wait for this to happen. > Attached a rebased patch to resolve t

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-31 Thread Michael Paquier
On Fri, Jan 27, 2017 at 10:26 AM, Haribabu Kommi wrote: > Thanks for the review. > Let's wait for the committer's opinion. I have moved this patch to CF 2017-03 to wait for this to happen. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-26 Thread Haribabu Kommi
On Tue, Jan 24, 2017 at 3:59 PM, Dilip Kumar wrote: > > Overall patch looks fine to me and marking it "ready for committer". > > There is two design decision, which I leave it for committer's decision. > > 1. EXECUTE statement should show only as EXECUTE count, not the > actual SQL query. > 2.

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-23 Thread Dilip Kumar
On Wed, Jan 18, 2017 at 10:45 AM, Haribabu Kommi wrote: > 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 q

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-19 Thread vinayak
On 2017/01/18 14:15, Haribabu Kommi wrote: On Sat, Jan 14, 2017 at 2:58 AM, Dilip Kumar > wrote: On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar mailto:dilipbal...@gmail.com>> wrote: > +void > +pgstat_count_sqlstmt(const char *commandTag) > +{

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-17 Thread Haribabu Kommi
On Sat, Jan 14, 2017 at 2:58 AM, Dilip Kumar wrote: > On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar > wrote: > > +void > > +pgstat_count_sqlstmt(const char *commandTag) > > +{ > > + PgStat_SqlstmtEntry *htabent; > > + bool found; > > + > > + if (!pgstat_track_sql) > > + return > > > > Callers of

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-17 Thread Robert Haas
On Fri, Jan 13, 2017 at 10:58 AM, Dilip Kumar wrote: > 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". Somebody might say that's a feature, not a bug. But then

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-16 Thread Michael Paquier
On Sat, Jan 14, 2017 at 12:58 AM, Dilip Kumar wrote: > On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar wrote: >> +void >> +pgstat_count_sqlstmt(const char *commandTag) >> +{ >> + PgStat_SqlstmtEntry *htabent; >> + bool found; >> + >> + if (!pgstat_track_sql) >> + return >> >> Callers of pgstat_count

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-13 Thread Dilip Kumar
On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar 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, seem

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-11 Thread Robert Haas
On Wed, Jan 11, 2017 at 9:17 AM, Dilip Kumar wrote: > On Mon, Dec 5, 2016 at 8:01 AM, Haribabu Kommi > wrote: >> Moved to next CF with "needs review" status. > > I have started reviewing the patch, Some initial comments. > > $ git apply ../pg_stat_sql_row_mode_2.patch > error: patch failed: src/

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2017-01-11 Thread Dilip Kumar
On Mon, Dec 5, 2016 at 8:01 AM, Haribabu Kommi wrote: > Moved to next CF with "needs review" status. I have started reviewing the patch, Some initial comments. $ git apply ../pg_stat_sql_row_mode_2.patch error: patch failed: src/include/catalog/pg_proc.h:2893 error: src/include/catalog/pg_proc.h

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-12-04 Thread Haribabu Kommi
On Tue, Nov 22, 2016 at 5:57 PM, Haribabu Kommi wrote: > Hi Vinayak, > > This is a gentle reminder. > > you assigned as reviewer to the current patch in the 11-2016 commitfest. > If you have any more review comments / performance results regarding the > approach of the patch, please share it. Oth

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-11-21 Thread Haribabu Kommi
Hi Vinayak, This is a gentle reminder. you assigned as reviewer to the current patch in the 11-2016 commitfest. If you have any more review comments / performance results regarding the approach of the patch, please share it. Otherwise, you can mark the patch as "Ready for committer" for committer

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-18 Thread Haribabu Kommi
On Wed, Oct 19, 2016 at 5:11 AM, Robert Haas wrote: > On Thu, Sep 29, 2016 at 1:45 AM, Haribabu Kommi > wrote: > > Currently, The SQL stats is a fixed size counter to track the all the > ALTER > > cases as single counter. So while sending the stats from the backend to > > stats collector at the

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-18 Thread Robert Haas
On Thu, Sep 29, 2016 at 1:45 AM, Haribabu Kommi wrote: > Currently, The SQL stats is a fixed size counter to track the all the ALTER > cases as single counter. So while sending the stats from the backend to > stats collector at the end of the transaction, the cost is same, because of > it's fixed

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-16 Thread vinayak
On 2016/10/17 10:22, Haribabu Kommi wrote: On Fri, Oct 14, 2016 at 7:48 PM, vinayak > wrote: On 2016/10/12 12:21, Haribabu Kommi wrote: I tried changing the pg_stat_sql into row mode and ran the regress suite to add different type of

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-16 Thread Haribabu Kommi
On Fri, Oct 14, 2016 at 7:48 PM, vinayak wrote: > > On 2016/10/12 12:21, Haribabu Kommi wrote: > > I tried changing the pg_stat_sql into row mode and ran the regress suite > to > add different type of SQL commands to the view and ran the pgbench test > on my laptop to find out any performance imp

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-16 Thread Haribabu Kommi
On Wed, Oct 12, 2016 at 4:06 PM, vinayak wrote: > > > Thank you for the patch. > > Test: Commands with uppercase and lowercase > > If the tag='select' then it returns the 0 rows but count is actually > increment by 1. > > tag='select' vs tag='SELECT' > > postgres=# SET track_sql TO ON; > SET

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-14 Thread vinayak
On 2016/10/12 12:21, Haribabu Kommi wrote: On Thu, Sep 29, 2016 at 3:45 PM, Haribabu Kommi mailto:kommi.harib...@gmail.com>> wrote: On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote: Peter Eisentraut wrote: > How about having

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-11 Thread vinayak
On 2016/10/12 12:21, Haribabu Kommi wrote: On Thu, Sep 29, 2016 at 3:45 PM, Haribabu Kommi mailto:kommi.harib...@gmail.com>> wrote: On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote: Peter Eisentraut wrote: > How about havin

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-10-11 Thread Haribabu Kommi
On Thu, Sep 29, 2016 at 3:45 PM, Haribabu Kommi wrote: > > > On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera > wrote: > >> Peter Eisentraut wrote: >> >> > How about having the tag not be a column name but a row entry. So you'd >> > do something like >> > >> > SELECT * FROM pg_stat_sql WHERE tag

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-28 Thread Haribabu Kommi
On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: > > > How about having the tag not be a column name but a row entry. So you'd > > do something like > > > > SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW'; > > > > That way, we don't have to keep updating (and r

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-21 Thread David Fetter
On Wed, Sep 21, 2016 at 02:05:24PM -0300, Alvaro Herrera wrote: > Another consideration is that the present patch lumps together all > ALTER cases in a single counter. This isn't great, but at the same > time we don't want to bloat the stat files by having hundreds of > counters per database, do w

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-21 Thread Alvaro Herrera
Peter Eisentraut wrote: > How about having the tag not be a column name but a row entry. So you'd > do something like > > SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW'; > > That way, we don't have to keep updating (and re-debating) this when new > command types or subtypes are added. And

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-21 Thread David Fetter
On Wed, Sep 21, 2016 at 11:25:14AM -0400, Peter Eisentraut wrote: > On 9/14/16 4:01 PM, Robert Haas wrote: > > I think it is not a good idea to make the command names used here the > > plural forms of the command tags. Instead of "inserts", "updates", > > "imports", etc. just use "INSERT", "UPDATE

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-21 Thread Peter Eisentraut
On 9/14/16 4:01 PM, Robert Haas wrote: > I think it is not a good idea to make the command names used here the > plural forms of the command tags. Instead of "inserts", "updates", > "imports", etc. just use "INSERT", "UPDATE", "IMPORT". That's simpler > and less error prone - e.g. you won't end u

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-20 Thread Haribabu Kommi
On Thu, Sep 15, 2016 at 6:01 AM, Robert Haas wrote: > On Fri, Sep 2, 2016 at 2:33 AM, Haribabu Kommi > wrote: > > On Wed, Aug 31, 2016 at 3:19 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > >> Haribabu Kommi wrote: > >> > >>> Apart from the above, here are the following list of co

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-14 Thread Robert Haas
On Fri, Sep 2, 2016 at 2:33 AM, Haribabu Kommi wrote: > On Wed, Aug 31, 2016 at 3:19 AM, Alvaro Herrera > wrote: >> Haribabu Kommi wrote: >> >>> Apart from the above, here are the following list of command tags that >>> are generated in the code, I took only the first word of the command tag >>>

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-09-01 Thread Haribabu Kommi
On Wed, Aug 31, 2016 at 3:19 AM, Alvaro Herrera wrote: > Haribabu Kommi wrote: > >> Apart from the above, here are the following list of command tags that >> are generated in the code, I took only the first word of the command tag >> just to see how many categories present. The number indicates th

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-30 Thread Alvaro Herrera
Haribabu Kommi wrote: > Apart from the above, here are the following list of command tags that > are generated in the code, I took only the first word of the command tag > just to see how many categories present. The number indicates the > subset of operations or number of types it is used. Like c

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-24 Thread Haribabu Kommi
On Tue, Aug 23, 2016 at 3:59 AM, Andres Freund wrote: >> Haribabu's categorization >> scheme seems to need some work, but the idea of categorizing >> statements by type and counting executions per type seems very >> reasonable. > > I'd consider instead using something like COALESCE(commandType, >

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-23 Thread neha khatri
On Wed, Aug 24, 2016 at 10:07 AM, Gavin Flower < gavinflo...@archidevsys.co.nz> wrote: > On 24/08/16 12:02, neha khatri wrote: > >> >Andres Freund mailto:and...@anarazel.de>> writes: >> >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane > t...@sss.

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-23 Thread Gavin Flower
On 24/08/16 12:02, neha khatri wrote: >Andres Freund mailto:and...@anarazel.de>> writes: >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane > wrote: I'm inclined to suggest you forget this approach and propose a singl

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-23 Thread neha khatri
>Andres Freund writes: >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: I'm inclined to suggest you forget this approach and propose a single counter for "SQL commands executed", which avoids all of the above definitional prob

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-22 Thread Gavin Flower
On 23/08/16 08:27, Tom Lane wrote: Andres Freund writes: On 2016-08-22 13:54:43 -0400, Robert Haas wrote: On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: I'm inclined to suggest you forget this approach and propose a single counter for "SQL commands executed", which avoids all of the above

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-22 Thread Tom Lane
Andres Freund writes: > On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: >>> I'm inclined to suggest you forget this approach and propose a single >>> counter for "SQL commands executed", which avoids all of the above >>> definitional problems.

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-22 Thread Andres Freund
On 2016-08-22 13:54:43 -0400, Robert Haas wrote: > On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: > > I'm inclined to suggest you forget this approach and propose a single > > counter for "SQL commands executed", which avoids all of the above > > definitional problems. People who need more det

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-22 Thread Robert Haas
On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: > I'm inclined to suggest you forget this approach and propose a single > counter for "SQL commands executed", which avoids all of the above > definitional problems. People who need more detail than that are > probably best advised to look to cont

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-21 Thread Haribabu Kommi
On Sun, Aug 21, 2016 at 1:17 AM, Tom Lane wrote: > Haribabu Kommi writes: >> This is a new statistics view that is used to provide the number of >> SQL operations that are >> happened on a particular interval of time. This view is useful for the >> system to find out the >> pattern of the operati

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-20 Thread Tom Lane
Haribabu Kommi writes: > This is a new statistics view that is used to provide the number of > SQL operations that are > happened on a particular interval of time. This view is useful for the > system to find out the > pattern of the operations that are happening in the instance during > particula

[HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-08-20 Thread Haribabu Kommi
This is a new statistics view that is used to provide the number of SQL operations that are happened on a particular interval of time. This view is useful for the system to find out the pattern of the operations that are happening in the instance during particular interval of time. Following is th