[
https://issues.apache.org/jira/browse/DERBY-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6022:
---------------------------------
Attachment: derby-6022-07-aa-optimizerTracingWithLogFile.diff
Attaching derby-6022-07-aa-optimizerTracingWithLogFile.diff. This patch lets
you specify a file to which the optimizer trace should be dumped. Committed at
subversion revision 1456579.
With this patch, you can dump the optimizer trace either to standard out or to
a file:
--
-- Turn on optimizer tracing, run one statement, turn off tracing, and print
trace to standard out.
--
call syscs_util.syscs_register_tool( 'optimizerTracing', true );
select columnname from sys.systables t, sys.syscolumns c where t.tableid =
c.referenceid and t.tablename = 'SYSROLES';
call syscs_util.syscs_register_tool( 'optimizerTracing', false );
--
-- Turn on optimizer tracing, run one statement, turn off tracing,
-- and print trace to a file named z1.txt.
--
call syscs_util.syscs_register_tool( 'optimizerTracing', true );
select columnname from sys.systables t, sys.syscolumns c where t.tableid =
c.referenceid and t.tablename = 'SYSALIASES';
call syscs_util.syscs_register_tool( 'optimizerTracing', false, 'z1.txt' );
In adding this functionality, I tripped across some unexpected behaviors of
optimizer tracing:
1) The knowledge of whether tracing is on is maintained in two state variables,
one in GenericLanguageConnectionContext and the other in Level2OptimizerImpl.
This seems brittle to me.
2) At one point it seems that someone intended to make it possible to print the
trace in html. But that effort wasn't completed. I'd be happy to add an xml
format to optimizer tracing if people are interested. You'd use this feature
like this:
call syscs_util.syscs_register_tool( 'optimizerTracing', true, 'xml' );
3) I can't tell whether optimizer tracing is only meant to operate on a single
statement or on multi-statement batches. The latter doesn't seem to work,
however. Again, if people are interested, I'd be happy to add multi-statement
support to optimizer tracing. This would be particularly useful with xml output
since it would then be easy to isolate the individual statements in the output.
Touches the following files:
M java/tools/org/apache/derby/impl/tools/optional/OptimizerTracer.java
M java/engine/org/apache/derby/iapi/db/OptimizerTrace.java
> Add a system procedure for (un)registering optional packages of Derby tools.
> ----------------------------------------------------------------------------
>
> Key: DERBY-6022
> URL: https://issues.apache.org/jira/browse/DERBY-6022
> Project: Derby
> Issue Type: Improvement
> Components: SQL, Tools
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
> Attachments: derby-6022-01-aa-registerToolProc.diff,
> derby-6022-02-aa-dbmdWrapper.diff, derby-6022-03-aa-foreignDBviews.diff,
> derby-6022-04-aa-customTool.diff, derby-6022-05-aa-schemaNotCreatedYet.diff,
> derby-6022-06-aa-optimizerTracing.diff,
> derby-6022-07-aa-optimizerTracingWithLogFile.diff
>
>
> Now that vararg routines have been added to Derby (see DERBY-3069), I would
> like to add a new vararg system procedure for registering and unregistering
> optional packages of Derby tools. For starters, these would be tools which
> aren't checked into the Derby codeline but are just attached to various
> JIRAs. These tools are:
> o DBMDWrapper (DERBY-3973 and DERBY-5967) - This tool creates functions and
> table functions for all of the DatabaseMetaData methods so that you can write
> complicated queries which join and filter JDBC metadata.
> o ForeignTableVTI (DERBY-4962) - This tool creates views against foreign
> databases so that you can bulk-import foreign data into Derby without
> indirecting through csv files.
> It also may be possible to use this approach to expose the log and data file
> reading tools attached to DERBY-5195 and DERBY-5201.
> The new system procedure would look like this:
> create procedure syscs_util.syscs_register_tool
> (
> toolName varchar( 32672 ),
> boolean register,
> optionalArgs varchar( 32672 ) ...
> )
> language java parameter style derby modifies sql data
> external name 'willFigureOutWhereToPutThis';
> The arguments would have these meanings:
> o toolName - A name specific to the tool.
> o register - True means "register the tool" and false means "unregister the
> tool".
> o optionalArgs - Each tool could have its own variable set of additional
> configuration parameters.
> By default, only the DBO could run this procedure. The DBO could grant
> execute permission to other users.
> The known tool names and their optional parameters would be documented in the
> Derby Reference Manual in the section on syscs_util.syscs_register_tool.
> I am thinking that we should put the optional tools themselves in
> derbytools.jar. We might want to document all of the optional tools in the
> Tools Guide, although I can see arguments for documenting some tools in the
> Admin Guide.
> I would appreciate other people's thoughts about this proposal.
> Thanks,
> -Rick
--
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
