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
