[Db-derby Wiki] Trivial Update of "LanguageOptimize" by Army

[Apache Wiki <wi...@apache.org>]

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().