Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 2 May 2013 12:46:15 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12645677.1367433465992.260110.1367498775806@arcas>
In-Reply-To: <JIRA.12645677.1367433465992@arcas>
References: <JIRA.12645677.1367433465992@arcas>
Subject: [jira] [Commented] (DERBY-6211) Make Optimizer trace logic
 pluggable.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rick Hillegas commented on DERBY-6211:
--------------------------------------

Hi Mamta,

I'm not planning to fix anything that isn't broken. I think that the RuntimeStatisticsParser does a good job of analyzing the plans chosen for many queries. But I think that there are limitations in the approach taken by RuntimeStatisticsParser: looking for the presence of specific strings in the runtime statistics output. For instance, the following RuntimeStatisticsParser method

   public boolean usedTableScan(String tableName)

...will give you useful information if a table is only scanned once by a query. But if a table is scanned more than once, then the method won't tell you which scan was the table scan. I'm hoping that a trace plugin will be able to give us the detailed structure of the plan. Thanks.
                
> 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
>
>
> 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