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
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:
>
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
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
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
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)
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
>
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
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,
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
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
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
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
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
14 matches
Mail list logo