db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Trivial Update of "LanguageOptimize" by Army
Date Fri, 27 Oct 2006 17:31:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by Army:
http://wiki.apache.org/db-derby/LanguageOptimize

------------------------------------------------------------------------------
  
  Then the call to "getNextDecoratedPermutation()" tells the optimizer to find out what the
next available "decorated permutation" is for the newly-placed Optimizable.  A "decorated
permutation" translates into an "access path" for the Optimizable.  Thus, as mentioned above,
it is composed of index choice plus join strategy for base tables, and is simply the join
strategy for non-base tables.  It is perhaps helpful to think of a decorated permutation as
a join order with indexes and join strategies that "decorate" the Optimizables.  For details
on how a "decoration" is chosen, see DecoratedPermutations.
  
- And finally, the call to "costPermutation()" tells the optimizer to figure out how much
it costs to have the Optimizable at it's current position with its current decorated permutation.
 As part of this method the !OptimizerImpl figures out which predicates in its list of predicates
can be evaluated at the current position in the join order. It then pushes those predicates
down to the most-recently-placed Optimizable, where they can in turn be used for costing.
 The determination of which predicates can be pushed--and the call to push them--is made in
the "pushOptPredicates()" method of !OptimizerImpl. See PredicatePushdown for more on that
method. See PermutationCosting for more on the code flow that results from a call to the costPermutation()
method.
+ And finally, the call to "costPermutation()" tells the optimizer to figure out how much
it costs to have the Optimizable at it's current position with its current decorated permutation.
 As part of this method the !OptimizerImpl figures out which predicates in its list of predicates
can be evaluated at the current position in the join order. It then pushes those predicates
down to the most-recently-placed Optimizable, where they can in turn be used for costing.
 The determination of which predicates can be pushed--and the call to push them--is made as
part of the "costPermutation()" method.  See PermutationCosting for more on the code flow
that results from a call to the costPermutation() method.
  
  When we have the cost of the Optimizable at its current position in the join order with
its current "decoration", the inner loop again calls getNextDecoratedPermutation().  That
method checks to see if the most-recently-estimated cost is the best one for the Optimizable
so far.  If so, the access path and cost are saved.  Then getNextDecoratedPermutation() will
search for the next "decorated permutation" of the Optimizable and, if it finds one, we will
again make the call to costPermutation().
  

Mime
View raw message