[
https://issues.apache.org/jira/browse/IGNITE-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595344#comment-15595344
]
Semen Boikov edited comment on IGNITE-3443 at 10/21/16 3:09 PM:
----------------------------------------------------------------
Hi Alexey,
Reviewed your changes, have few comments:
- GridCacheQueryType is internal class, it can not be used on pulbic API in
QueryDetailsMetrics
- did you try to execute some of sql benchmarks to check new metrics overhead?
Could you please do it, maybe we need optimize 'collectMetrics' metod (e.g.
check if 'get/replace' work better than 'remove/putIfAbsent'. Sql string is
used as map key, so for long strings 'equals/hasCode' potentially can be
slow).
- should it work for SqlQuery? I do not see SqlQuery in tests
- what happens if sql query is splitted into map/reduce maps? should we store
both map/reduce queries in metrics?
- GridCacheQueryManager.collectMetrics:
{noformat}
if (failed || completed) {
...
}
{noformat}
When both failed and completed can be 'false'? Is it valid case?
- there is no need to create qryHist map at all if qryHistSz=0
- does it make sense to validate that history size is >=0? (if yes, let's add
this check in GridCacheProcessor.validate)
Thanks!
was (Author: sboikov):
Hi Alexey,
Reviewed your changes, have few comments:
- GridCacheQueryType is internal class, it can not be used on pulbic API in
QueryDetailsMetrics
- did you try to execute some of sql benchmarks to check new metrics overhead?
Could you please do it, maybe we need optimize 'collectMetrics' metod (e.g.
check if 'get/replace' work better than 'remove/putIfAbsent'. Sql string is
used as map key, so for long strings 'equals/hasCode' potentially can be
slow).
- GridCacheQueryManager.collectMetrics:
{noformat}
if (failed || completed) {
...
}
{noformat}
When both failed and completed can be 'false'? Is it valid case?
- there is no need to create qryHist map at all if qryHistSz=0
- does it make sense to validate that history size is >=0? (if yes, let's add
this check in GridCacheProcessor.validate)
Thanks!
> Implement collecting what SQL statements executed on cluster and their
> metrics.
> -------------------------------------------------------------------------------
>
> Key: IGNITE-3443
> URL: https://issues.apache.org/jira/browse/IGNITE-3443
> Project: Ignite
> Issue Type: Task
> Components: SQL
> Reporter: Alexey Kuznetsov
> Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
>
> We could collect last 1000 (maybe configurable) sql statements with per
> statement statistics: count, min time, max time, avg time,....
> May be execution plan (explain) ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
