On Sun, Aug 21, 2016 at 1:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Haribabu Kommi <kommi.harib...@gmail.com> 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 >> particular interval of >> time. > > 1. This set of counters seems remarkably random. Why, for instance, > count reindexes but not original index creations?
I thought of adding the columns to the view that are mostly used(excluding all DDL commands), otherwise the view columns fill with all the commands that are supported by PostgreSQL. > 2. What will you do with cases such as SELECTs containing modifying CTEs? > Or EXPLAIN ANALYZE? Does CLUSTER count as a REINDEX? Does REFRESH > MATERIALIZED VIEW count as a SELECT? (Or maybe it's an INSERT?) Cluster commands will be calculated as clusters, explain needs some logic to identify what SQL operation exactly. This is because of using nodeTag data from the parseTree structure to identify what type of SQL statement it is. The counters will not updated for any SQL type that is not as part of the view. > If you're going to be selective about what you count, you're forever > going to be fielding complaints from users who are unhappy that you > didn't count some statement type they care about, or feel that you > misclassified some complex case. Yes, I agree that users may complain regarding with limited columns that are not sufficient for their use. But with the mostly used columns, this view may be useful for some of the users to find out the pattern of the SQL operations that are happening on the instance. > 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 contrib/pg_stat_statements, anyway. I will add a new column to the pg_stat_database, to track the number of SQL operations that are happened on this particular database. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
