[jira] [Commented] (CALCITE-453) Revisit/introduce/document tracing framework to debug/investigate planning issues

["Julian Hyde (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196631#comment-14196631 ] 

Julian Hyde commented on CALCITE-453:
-------------------------------------

This is much needed.

I think a logging framework (j.u.l or log4j or similar) can let us put different logging streams in different files, enable logging dynamically, etc. We should lean on the framework as much as possible for this stuff.

Which leaves tracing. There definitely isn't enough right now. I added '-Dcalcite.debug' and printing to stdout and I know that is lame.

I like your approach of choosing particular tasks that need supporting tracing. Let me know if I can help.

Regarding documentation. In LucidDB we had a policy of defining loggers (tracers) for each major component, and declaring them in http://www.hydromatic.net/calcite/apidocs/org/eigenbase/trace/EigenbaseTrace.html. (This class will be org.apache.calcite.util.trace.CalciteTrace after I have completed CALCITE-296.) And I documented our tracing in https://github.com/apache/incubator-calcite/blob/master/doc/HOWTO.md#tracing. I think we should carry on with this policy, just add more tracers, tracing and documentation. Do you agree?

> Revisit/introduce/document tracing framework to debug/investigate planning issues
> ---------------------------------------------------------------------------------
>
>                 Key: CALCITE-453
>                 URL: https://issues.apache.org/jira/browse/CALCITE-453
>             Project: Calcite
>          Issue Type: New Feature
>    Affects Versions: 0.9.1
>            Reporter: Vladimir Sitnikov
>            Assignee: Julian Hyde
>
> Calcite lacks solid tracing that can help resolving planning/execution issues.
> Current tracing/debug code is a mix of {{System.out}}/{{log.FINXXX}} and it is not very friendly unless you run just a single query in the whole life of JVM.
> It would be good if Calcite had more robust logging for debugging and root-cause-analysis purposes.
> I expect the following user of the traces:
> U1) Calcite developers
> U2) Rule developers
> U3) Users who just run Calcite-powered stuff
> I expect the following questions:
> Q1) How do I collect relevant data for the bug report?
> Q2) Why -the index is not used- the rule did not work?
> Q3) Was this plan ever considered?
> Q4) What is the initial/optimized/execution plan?
> Q5) What is the generated/interpreted code?
> Q6) What are the cost calculations?
> I expect the following features might be good:
> F0) Document the way to collect the information
> F1) Collect traces to different files. For instance: per tracing session, per top-level-query
> F3) Ability to enable trace based on the sql match (e.g. trace a particular query)
> F4) Ability to enable trace based on rule fire
> F2) Ability to enable/disable trace when the app is running



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)