Re: New SQL counter statistics view (pg_stat_sql) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: New SQL counter statistics view (pg_stat_sql)
Date
Msg-id 20160830171924.GA509761@alvherre.pgsql
Whole thread Raw
In response to Re: New SQL counter statistics view (pg_stat_sql)  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: New SQL counter statistics view (pg_stat_sql)  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
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 create table,
> create function and etc.

Sounds about right.  I suppose all those cases that you aggregated here
would expand to full tags in the actual code.  I furthermore suppose
that some of these could be ignored, such as the transaction ones and
things like load, lock, move, fetch, discard, deallocate (maybe lump
them all together under "other", or some other rough categorization, as
Tom suggests).  Also, for many of these commands it's probably relevant
whether they are acting on a temporary object or not; we should either
count these separately, or not count the temp ones at all.

> insert
> delete
> update
> select (6)
> transaction (10)
> declare
> close (2)
> move
> fetch
> create (37)
> drop (36)
> Alter (56)
> import
> truncate
> comment
> security
> copy
> grant
> revoke
> notify
> listen
> unlisten
> load
> cluster
> vacuum
> analyze
> explain
> refresh
> set (2)
> reset
> show
> discard (4)
> reassign
> lock
> checkpoint
> reindex
> prepare
> execute
> deallocate

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Missing checks when malloc returns NULL...
Next
From: Heikki Linnakangas
Date:
Subject: Re: Pinning a buffer in TupleTableSlot is unnecessary