db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6211) Make Optimizer trace logic pluggable.
Date Fri, 02 Aug 2013 12:43:49 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rick Hillegas updated DERBY-6211:

    Attachment: derby-6211-10-aa-makingCostEstimateObject.diff

Attaching derby-6211-10-aa-makingCostEstimateObject.diff. This patch simplifies the construction
of CostEstimate objects and fixes an NPE when running XML-based optimizer tracing against
an outer join query. Tests passed cleanly for me on this patch.

While investigating the optimizer's handling of outer joins, I tripped across 2 problems:

1) The xml-based optimizer tracer dies on an NPE in trying to assign a table name to the ProjectRestrictNode
which sits on top of the outer join node. The fix, for the moment, is to give the ProjectRestrictNode
a generic name.

2) During outer join optimization, other optimizers are created for the sole purpose of asking
them to manufacture empty CostEstimate objects. This is wrong for several reasons:

a) It violates the principle that an optimizer instance corresponds to a query block.

b) It's inefficient.

c) It's unnecessary because there is already a method on OptimizerFactory for creating an
empty CostEstimate object.

The fix to (2) is to make Optimizer.newCostEstimate() private, remove the pointless instantiations
of new optimizers, and call OptimizerFactory.getCostEstimate() to make empty CostEstimates.

Touches the following files:


M       java/engine/org/apache/derby/impl/sql/compile/XMLOptTrace.java

Changes for (1).


M       java/engine/org/apache/derby/iapi/sql/compile/OptimizerFactory.java
M       java/engine/org/apache/derby/iapi/sql/compile/Optimizer.java
M       java/engine/org/apache/derby/impl/sql/compile/FromTable.java
M       java/engine/org/apache/derby/impl/sql/compile/SingleChildResultSetNode.java
M       java/engine/org/apache/derby/impl/sql/compile/DistinctNode.java
M       java/engine/org/apache/derby/impl/sql/compile/ProjectRestrictNode.java
M       java/engine/org/apache/derby/impl/sql/compile/GroupByNode.java
M       java/engine/org/apache/derby/impl/sql/compile/OptimizerFactoryImpl.java
M       java/engine/org/apache/derby/impl/sql/compile/RowResultSetNode.java
M       java/engine/org/apache/derby/impl/sql/compile/CurrentOfNode.java
M       java/engine/org/apache/derby/impl/sql/compile/OptimizerImpl.java
M       java/engine/org/apache/derby/impl/sql/compile/TableOperatorNode.java

Changes for (2).

> 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:
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>              Labels: derby_triage10_11
>         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,
derby-6211-07-aa-useSchemaQualifiedNamesInSummaries.diff, derby-6211-07-ab-useSchemaQualifiedNamesInSummaries.diff,
derby-6211-08-aa-fixNPE.diff, derby-6211-09-aa-addTests.diff, derby-6211-10-aa-makingCostEstimateObject.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

View raw message