db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4587) Add tools for improved analysis and understanding of query plans and execution statistics
Date Thu, 12 Aug 2010 19:53:17 GMT

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

Kristian Waagan commented on DERBY-4587:

Nirmal, some answers to your questions about my comments:

--- AccessDatabase 
c) Well, the easiest is probably to use PreparedStatement and ps.setString(x, s).
    By specifying a system table and a comment as the schema, say "sys.systables --", or saying
"<stmt_id> and 1 = 1" in a where clause, one can make the tool query tables it isn't
supposed to access. Nothing severe in this case, but it's good to be aware of these issues
in general. Luckily you cannot specify multiple SQL statements in (most?) JDBC calls, because
then you could easily add delete or update statements as well.
    You could also use Connection.getMetaData(), and then use one of the DatabaseMetaData.getSchemas()
methods to verify that the schema actually exists.

--- CreateXMLFile
n) Since you know only an IOException can be thrown within the PrivilegedExceptionAction,
you can add a try - catch block where you unwrap the IOException, something like this:
    try {
        // PrivilegedActionException wrapping IOException thrown here somewhere
    } catch (PrivilegedActionException pae) {
        throw (IOException)pae.getCause(); // or, according to the old API, pae.getException().

    You can then remove PrivilegedActionException from the throws clause of the method.

p) I'm not quite sure. I don't have the cycles to follow up on this one right now, so it would
be nice if someone else can give you more feedback on this. If you don't hear anything, it's
probably not a big issue.

I also noticed that CreateHTMLFile only contains a method that could have been static. If
you want to keep the class, you should make the no-arg constructor private and the getHTML-method
static. Alternatively, you could move the method into CreateXMLFile or somewhere else. Your
call :)


> 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: AdavancedXSL-mouseover.jpg, advancedViewXSL.xsl, advancedViewXSL.xsl,
advancedViewXSL2.xsl, advancedXSL-1.jpg, advancedXSL-2.jpg, advancedXSL-3.jpg, 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-javadoc_fix.diff, 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.10-eol_style_native.diff,
DERBY-4587-tool-9.2.diff, DERBY-4587-tool-9.3.diff, DERBY-4587-tool-9.4.diff, DERBY-4587-tool-9.5.diff,
DERBY-4587-tool-9.6.diff, DERBY-4587-tool-9.7.diff, DERBY-4587-tool-9.7.diff, DERBY-4587-tool-9.8-modified.diff,
DERBY-4587-tool-9.8.diff, DERBY-4587-tool-9.9-formatting.diff, DERBY-4587-tool-9.diff, DERBY-4587-tool-test1.diff,
DERBY-4587-tool-test2.diff, DERBY-4587-tool.diff, derby-logo.png, 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, 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