db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4587) Add tools for improved analysis and understanding of query plans and execution statistics
Date Thu, 15 Jul 2010 01:08:50 GMT

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

Bryan Pendleton commented on DERBY-4587:

Yes, at the outermost level of PlanExporter I think it is appropriate
to catch (Exception); we don't need to name each specific type
of exception there unless they would have different handling.

In the test code, we generally don't catch exceptions at all. We
generally just declare our test methods as

  throws Exception

and let the exception be thrown out to JUnit, which will catch it
and report it. The one exception (!) to this rule is for a test which
is deliberately testing the throwing of an exception, in which case
the test catches the exception (and, in fact, should call fail() if the
exception is not thrown)

So yes, it's fine to have the test methods declare that they throw
exceptions, and the test code should only catch the exceptions
that the test case is deliberately provoking with its testing.

I thought we had written something about this in the Derby wiki,
but I went searching under http://wiki.apache.org/db-derby/IntroToJUnit
and I couldn't find it. Does anybody know if we wrote a wiki
page describing these coding conventions for JUnit tests?  If
not, it would be great to have one.

> Add tools for improved analysis and understanding of query plans and execution statistics
> -----------------------------------------------------------------------------------------
>                 Key: DERBY-4587
>                 URL: https://issues.apache.org/jira/browse/DERBY-4587
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Tools
>            Reporter: Bryan Pendleton
>            Assignee: C.S. Nirmal J. Fernando
>         Attachments: basic_html-2.2.jpg, basic_html-2.3.jpg, basic_html-2.jpg, basic_html-3.jpg,
basic_html-4.1.jpg, basic_html-4.2.jpg, Derby Query Plan Screen Shot 2.jpg, DERBY-4587-tool-2.diff,
DERBY-4587-tool-3.diff, DERBY-4587-tool-4.diff, DERBY-4587-tool-5.diff, DERBY-4587-tool-6.diff,
DERBY-4587-tool-7-b.diff, DERBY-4587-tool-7.diff, DERBY-4587-tool-8.diff, DERBY-4587-tool-9.1.diff,
DERBY-4587-tool-9.2.diff, DERBY-4587-tool-9.diff, DERBY-4587-tool-test1.diff, DERBY-4587-tool-test2.diff,
DERBY-4587-tool.diff, Derby_Query_Plan_Screen_Shot.jpg, PostgreSQL license.jpg, Read_Me.txt,
screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, Simple HTML View (Pure XSL).jpg, Source.rar,
test.xml, test4.xsl, vanilla_html.xsl, vanilla_html.xsl, vanilla_html.xsl, vanilla_html.xsl,
xml_doc_screenshot.jpg, xml_doc_screenshot.jpg
> I think it would be great to see some work in the area of tools for helping
> with the analysis of complex query execution. Quite frequently, users of
> Derby have trouble comprehending (a) how their query is being translated
> into a query plan by the optimizer, and (b) what the execution-time resource
> usage of the various parts of the query is.
> There are low-level features in Derby which capture this information and
> record it, such as logQueryPlan, and the XPLAIN tables, but there is a lot
> of opportunity for designing higher-level tools which can process the query
> plan and execution statistics information and present it in a more
> comprehensible fashion. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message