db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@gmail.com>
Subject Re: questions about querytreenode and optimization
Date Thu, 12 Jul 2007 18:39:55 GMT
Aakash Bordia wrote:
> I wanted to mention that I am in the debugger, and whatever I asked was
> in context of that (that is while debugging the code, I am not sure
> where to find the access path in the QTN once the optimize method is
> done with. Same for the second question).

<snip>

>> > 1) I am not sure where to look for the accesspath(both base tables and
>> > join),  

If you're looking for the *final* join strategies, index choices, and join order 
for a query, then one option is to set the derby.language.logQueryPlan property 
to "true".  Then after you execute a query and close the result set, the full 
query plan will be printed to the "derby.log" file.  For large queries the plan 
can be a bit unruly, but generally speaking you can find the join strategy, join 
order, and choice of conglomerate (index or base table) along with other scan 
information from that plan.

>> > as the values in AccessPathImpl (at join or PRN or base table
>> > level) seem un-intuitive.

AccessPathImpl is in fact the description of the access path for a given node. 
This object shows you the join strategy and conglomerate choice (index or base 
table) for a query tree node.  The latter (conglomerate) only applies to base 
tables.  The "conglomerate descriptor" within AccessPathImpl can be used to 
determine whether or not it's an index, and if so, which one.

If you're looking for the access path after optimization is complete, then you 
might want to put a breakpoint in DMLStatementNode.optimizeStatement(), right 
after the line which says:

   resultSet = resultSet.modifyAccessPaths()

When "modifyAccessPaths()" returns, all decisions regarding access paths have 
been made and have been saved within each query tree node.  So then you can 
examine the tree rooted at "resultSet" to see all of the information you want. 
Look for the "trulyTheBestAccessPath" field for a given node; if that field is 
null or if it doesn't have the information you need, then the node probably has 
one or more children at which you should look.

Note that if you are examining access paths *during* optimization, then 
"trulyTheBestAccessPath" will not be set.  Instead you should look at the 
"currentAccessPath" and "bestAccessPath" fields.

That said, trulyTheBestAccessPath (along with the other access path fields) is 
in fact an instance of AccessPathImpl, so if you find that to be non-intuitive, 
then perhaps your best bet is to use the query plan logging mentioned above?

>> > 2) Also it seems we hang the Level2OptimizerImpl objects off of the
>> > base table FromBaseTable, but I dont see it up in the tree anywhere.
>> > Is there a reason for this?

I'm not sure I understand what this question is asking; can you rephrase it?

I'm glad to see that you are interested in the optimizer.  If you are looking 
for more details about how things work (or how are they supposed to work), you 
might want to take a look at the following page from the Derby wiki:

   http://wiki.apache.org/db-derby/LanguageOptimize

That may help you figure out where to trace while debugging, as well.  If you 
have any questions, please feel free to ask.

Army


Mime
View raw message