[
https://issues.apache.org/jira/browse/DERBY-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681167#comment-13681167
]
Rick Hillegas commented on DERBY-6211:
--------------------------------------
Hi Mike,
The xml-based tracing adds 2 new classes to the engine jar:
o XMLOptTrace. This is the xml tracer. It needs to be in the engine jar because
it references many engine classes. It weighs 23K.
o OptTraceViewer. This is the code which loads and unloads the optional tool
for viewing the xml output. It weighs 4K.
Here's how xml-based tracing affects Derby processing:
o If you don't turn on optimizer tracing, then there is no effect. That is
because the tracing methods are only called if tracing is turned on. No new
tracing methods have been added.
o If you turn on optimizer tracing and you use the old-style tracer, then there
is a tiny effect: one extra (unused) argument apiece has been added to the
signatures of two tracing methods. I don't think that this extra argument
passing will give rise to any measurable performance drag.
o If you turn on optimizer tracing and you use xml-based tracing, then for some
trace calls, the tracing may create more transient objects. Other trace calls,
which are NOPs in the xml-tracer, will create fewer transient objects. I
haven't measured the performance effects of turning on either style of tracing.
Thanks,
-Rick
> 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
>
>
> 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
