deletions | additions       diff --git a/Section_Apache_Derby_Architecture_subsection__.tex b/Section_Apache_Derby_Architecture_subsection__.tex  index 7aa6d70..b33b931 100644  --- a/Section_Apache_Derby_Architecture_subsection__.tex  +++ b/Section_Apache_Derby_Architecture_subsection__.tex 
...
expressions down to that position so they can be used there. For example, if you have a five-way join of tables t1, t2, t3, t4 and t5, and the current permutation being considered is t3 - t1 - t2 (with t3 as the outermost table and t2 as the  innermost), it can evaluate the join ”t3.c1 = t2.c2” at the third position in the join order, so when it adds table t2 it pushes the expression down to that level in the order. Later, when it  removes t2 from the join order to consider some other table there, it pulls the expression back out of the join order.  getNextPermutation() does the adding (and deletion) of tables to the join order under consideration by the optimizer. getNextDecoratedPermutation() goes through all  the access paths for the current permutation (in the current implementation, it only has to consider the access paths for the innermost table in the join order, as the search is done depth-first). You can think of a decorated permutation as a join order with things like indexes and join strategies ”decorating” the nodes.  The Optimizable interface represents anything in the query that can have an access path. In practice an Optimizable is usually a base table, but it can be anything that appears in a FROM list (for example, standard SQL allows a UNION in the FROM list). Different Optimizables have different choices for access paths. The optimizer uses the nextAccessPath()