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

From neha khatri
Subject Re: New SQL counter statistics view (pg_stat_sql)
Date
Msg-id CAFO0U+8bSzsjtpy_6gZkGtGEckrbscwTowkuDnhxjSSNo6L5Bw@mail.gmail.com
Whole thread
In response to Re: New SQL counter statistics view (pg_stat_sql)  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-hackers

On Wed, Aug 24, 2016 at 10:07 AM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
On 24/08/16 12:02, neha khatri wrote:
>Andres Freund <andres@anarazel.de <mailto:andres@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 <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> 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 contrib/pg_stat_statements, anyway.

>>> I disagree.  I think SQL commands executed, lumping absolutely
>>> everything together, really isn't much use.

>> I'm inclined to agree. I think that's a quite useful stat when looking
>> at an installation one previously didn't have a lot of interaction with.

>Well, let's at least have an "other" category so you can add up the
>counters and get a meaningful total.

How would that meaningful total might help a user. What can a user might analyse with the counter in 'other' category.



The user could then judge if there were a significant number of examples not covered in the other categories - this may, or may not, be a problem; depending on the use case.


Cheers,
Gavin

For the user to be able to judge that whether the number in the 'other' category is a problem or not, the user is also required to know what all might fall under the 'other' category. It may not be good to say that _anything_ that is not part of the already defined category is part of 'other'. Probably, 'other' should also be a set of predefined operations.

Neha

pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Next
From: Tom Lane
Date:
Subject: Re: dump/restore doesn't preserve row ordering?