[
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)
