[
https://issues.apache.org/jira/browse/DERBY-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687642#comment-13687642
]
Dag H. Wanvik edited comment on DERBY-6211 at 6/19/13 5:56 AM:
---------------------------------------------------------------
I took the XML tracing for a test drive, also using the optional view tool to
check the results and I think the functionality is useful. I haven't really
done enough work in the optimizer to be able to say what possible extra trace
might be useful, but it seems straight forward to add more tracing as we see
the need.
The new notation is helpful to quickly grok what plan has been selected.
Question: If I do this twice, e.g one with XML, one with standard text, as in
this stanza, I see no proper trace in round two. Why? (possible answer below)
connect 'jdbc:derby:memory:wombat;create=true';
create table t(i int primary key, j int);
insert into t values (1,1),(2,2);
call syscs_util.syscs_register_tool( 'optimizerTracing', true);
select * from t a, t b;
call syscs_util.syscs_register_tool( 'optimizerTracing', false,
'plan.txt');
call syscs_util.syscs_register_tool( 'optimizerTracing', true, 'xml');
select * from t a, t b;
call syscs_util.syscs_register_tool( 'optimizerTracing', false,
'plan.xml');
It doesn't matter if I use xml or traditional trace, the second time, I see no
real plan in the output file. I guess the statement cache tricks us here...
It it a tad confusing for the user... perhaps we could force recompilation the
next statement after we register optimizer tracing?
was (Author: dagw):
I took the XML tracing for a test drive, also using the optional view tool
to check the results and I think the functionality is useful. I haven't really
done enough work in the optimizer to e able to say what possible extra trace
might be useful, but it seems straight forward to add more tracing as we see
the need.
The new notation is helpful to quickly grok what plan has been selected.
Question: If I do this twice, e.g one with XML, one with standard text, as in
this stanza, I see no proper trace in round two. Why?
connect 'jdbc:derby:memory:wombat;create=true';
create table t(i int primary key, j int);
insert into t values (1,1),(2,2);
call syscs_util.syscs_register_tool( 'optimizerTracing', true);
select * from t a, t b;
call syscs_util.syscs_register_tool( 'optimizerTracing', false,
'plan.txt');
call syscs_util.syscs_register_tool( 'optimizerTracing', true, 'xml');
select * from t a, t b;
call syscs_util.syscs_register_tool( 'optimizerTracing', false,
'plan.xml');
It doesn't matter if I use xml or traditional trace, the second time, I see no
real plan in the output file. I guess the statement cache tricks us here...
It it a tad confusing for the user... perhaps we could force recompilation the
next statement after we register optimizer tracing?
> Make Optimizer trace logic pluggable.
> -------------------------------------
>
> Key: DERBY-6211
> URL: https://issues.apache.org/jira/browse/DERBY-6211
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-6211-01-aa-createPlugin.diff,
> derby-6211-02-aa-cleanup.diff, derby-6211-02-ab-cleanup.diff,
> derby-6211-03-aa-customTracer.diff,
> derby-6211-04-aa-moveOptimizerTracerToEngineJar.diff,
> derby-6211-05-aa-xmlOptimizerTracer.diff,
> derby-6211-06-ab-packageProtect-XMLOptTrace.diff
>
>
> Right now the trace logic in the optimizer is hard-coded to produce a stream
> of diagnostics. It would be good to be able to plug alternative trace logic
> into the optimizer. This would make the following possible:
> 1) Plug in trace logic which produces formats which are easier to study and
> which can be analyzed mechanically. E.g., xml formatted output.
> 2) Plug in trace logic which can be used during unit testing to verify that
> the optimizer has picked the right plan. Over time this might make it easier
> to migrate canon-based tests to assertion-based tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
