I think some of the metrics specified by Denis also make sense, so I would add them as well. See below...
On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov <[email protected]> wrote: > Denis, > > Query execution is complex process involving different stages which are not > very easy to match with each other. Especially provided that any node can > leave topology at any time. Another problem is that engine evolves and > metrics like "did a query do broadcast or unicast" may easily become > useless at some point, because for example there will be neither unicast, > nor broadast, but something different. On the other hand I completely agree > that performance monitoring is essential part of any mature DBMS. > > I would start with metrics which are both very basic and easy to implement > at the same time. For example we can add fingerprint (hash) to every query > which will be used to join "map" and "reduce" parts with each other and add > the following basic metrics: > 1) Execution count for particular query > 2) Number of map nodes - min, max, avg > (1) and (2) makes sense > 3) Map step duration (if applicable) - min, max, 4) Reduce step duration (if applicable) - min, max, avg > Not sure if (3) and (4) are needed. I would only add them if they are easy to implement. I would also add these: 5) Collocated: yes/no 6) last execution time 7) min/max/average execution duration > > Once done users will be able to get statistics for particular queries. > > Vladimir. > > > On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda <[email protected]> wrote: > > > BTW, > > > > What if we expose per-query metrics below as a part of EXPLAIN ANALYZE? > > Sergi, is this feasible? > > > > — > > Denis > > > > > On Feb 27, 2017, at 2:35 PM, Denis Magda <[email protected]> wrote: > > > > > > Igniters, > > > > > > Let’s shed more light on SQL query execution internals introducing a > set > > of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757). > > > > > > Per-query metrics. Total history size is defined by > *CacheConfiguration. > > getQueryDetailMetricsSize*: > > > * if a query was executed in the collocated or non-collocated mode. > > Three results are valid: collocated, non-collocated, simple query (no > > joins). > > > * non-collocated query: size of the data exchanged between the nodes to > > complete a join. > > > * non-collocated query: did a query do broadcast or unicast to get data > > needed to complete a join. > > > * non-collocated and collocated query: a part of the time spent joining > > the data. > > > > > > CacheMetrics: > > > * an average number of executed SQL queries (collocated, > non-collocated, > > simple query (no joins)). > > > > > > Please don’t hesitate do share suggest another metrics or improve > > proposed ones. > > > > > > — > > > Denis > > > > >
