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 <and...@anarazel.de <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.pgh.pa.us <mailto: >> t...@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