Re: Additional SQL metrics

2017-03-06 Thread Denis Magda
Summarized the discussion updating ticket’s description: https://issues.apache.org/jira/browse/IGNITE-4757 — Denis > On Mar 3, 2017, at 11:14 AM, Dmitriy Setrakyan wrote: > > On Fri, Mar 3, 2017 at 11:07 AM, Denis Magda wrote: > >> What you’re saying

Re: Additional SQL metrics

2017-03-03 Thread Dmitriy Setrakyan
Hm... as a user I would be interested to know that, say, 95% of my "select * from sometable where..." query executes under 10ms or so. I think holding some history is important and is not that hard to implement. D. On Fri, Mar 3, 2017 at 10:55 AM, Denis Magda wrote: >

Re: Additional SQL metrics

2017-03-03 Thread Denis Magda
Sergey, agree, good point! Igniters, any other thoughts before we wrap up the discussion updating the ticket content? — Denis > On Mar 3, 2017, at 10:06 AM, Valentin Kulichenko > wrote: > > Sergey, that's great idea! Generally, user is not interested much in

Re: Additional SQL metrics

2017-03-03 Thread Valentin Kulichenko
Sergey, that's great idea! Generally, user is not interested much in some average numbers, especially in case of SQL queries. What they need is a list of slow queries and detailed information about the execution flow of these particular queries. -Val On Fri, Mar 3, 2017 at 2:50 AM, Sergey Kozlov

Re: Additional SQL metrics

2017-03-03 Thread Sergey Kozlov
One more comment: In general the customer is interested in slow queries details thus we can introduce an option which will allow to store only queries executed more than NNN seconds. It may significantly reduce the the memory consumption for history (but logging of all queries is still available

Re: Additional SQL metrics

2017-03-02 Thread Denis Magda
Vovan, When I’m speaking of JOIN metrics I’m simply assume that we need to add metrics relevant for queries with joins, metrics that will help us get more insights on non-collocated and collocated joins execution flow. > 1) Query exec count > 2) Query exec time (first define what "time" means)

Re: Additional SQL metrics

2017-03-02 Thread Dmitriy Setrakyan
Vladimir, are you talking about per-query metrics? On Thu, Mar 2, 2017 at 1:32 PM, Vladimir Ozerov wrote: > Denis, > > The main problem with suggested metrics is that they implies that ceratin > internal mechanics work in predefined way. For example, what is JOIN >

Re: Additional SQL metrics

2017-03-02 Thread Vladimir Ozerov
Denis, The main problem with suggested metrics is that they implies that ceratin internal mechanics work in predefined way. For example, what is JOIN metrics? There are no guarantees that JOIN in user's query will be translated to a real physical join. What if several different query execution

Re: Additional SQL metrics

2017-03-02 Thread Dmitriy Setrakyan
By the way, I am assuming that we are talking about per-query metrics, in which case we should specify metrics history size, so we don't keep all the queries in memory forever. I don't think it makes sense to have metrics aggregated across the queries. Just wanted to clarify this. On Thu, Mar 2,

Re: Additional SQL metrics

2017-03-02 Thread Denis Magda
Vovan, Your metrics make perfect sense to me. However, I see a high demand for JOINs based metrics especially from those who give a try to non-collocated joins in production and want to measure them somehow. This is why, personally, I prefer to see the metrics below in the top priority list

Re: Additional SQL metrics

2017-03-02 Thread Dmitriy Setrakyan
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 wrote: > Denis, > > Query execution is complex process involving different stages which are not > very easy to match

Re: Additional SQL metrics

2017-03-02 Thread Vladimir Ozerov
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

Re: Additional SQL metrics

2017-02-27 Thread Denis Magda
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 wrote: > > Igniters, > > Let’s shed more light on SQL query execution internals introducing a set of > useful metrics

Additional SQL metrics

2017-02-27 Thread Denis Magda
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