db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aakash Bordia" <bor...@gmail.com>
Subject Re: questions about querytreenode and optimization
Date Thu, 12 Jul 2007 19:47:25 GMT
Hello, Thanks for your response. You asked me about:
>> > 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?

What I meant is , after the modifyAccessPaths() has returned, I would expect
an overall optimizer object to hang off of the top cursornode which tells me
the enitre access strategy, but I see optimizer(Level2OptimizerImpl) as a
member of the trulyTheBestAccessPath wherever it is not null. I think this
is more of a design question than anything else. I am coming from another
compiler background, where the query tree and the optimizer plan are 2
different data structures. But in Derby, everything is going off of the same
tree and the separation of concerns is not that much, which is ok I think.
Just a different approach. I am guessing the class generation needs that
optimizer object at every node where there is a trulyTheBestAccessPath.

Thanks
Aakash



On 7/12/07, Army <qozinx@gmail.com> wrote:
>
> 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.logQueryPlanproperty
> 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