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] Update of "XmlOptimizerTracing" by RichardHillegas
Date Fri, 13 Dec 2013 18:11:05 GMT
Dear Wiki user,

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

The "XmlOptimizerTracing" page has been changed by RichardHillegas:
https://wiki.apache.org/db-derby/XmlOptimizerTracing?action=diff&rev1=2&rev2=3

   * '''Join Order''' - For each query block, the optimizer considers all possible left-to-right
orders of the optimizables. A left-to-right join order gives rise to a corresponding left-deep
join tree. Join orders start out as partial, incomplete lists of optimizables and are built
up incrementally. If a partial join order survives short-circuiting (described below), the
optimizer adds another optimizable to the right end of the partial join order and continues
analysis.
   * '''Slot''' - Each position in the join order is called a slot.
   * '''Conglomerate''' - A table is stored on disk as a number of files, also called conglomerates.
Each table has a heap conglomerate, which is just the raw, unordered set of rows. There is
a separate, btree conglomerate for every index on the table. There is also a separate, btree
conglomerate for every primary, unique, and foreign key on the table.
-  * '''Join strategy''' - A join strategy indicates how an optimizable joins to the optimizables
to its left in the join order. Derby currently supports two join strategies: !NestedLoop and
!HashJoin. The !NestedLoop strategy means that the whole optimizable is read for every composite
row which percolates up out of the slots to the left. The !HashJoin strategy means that the
whole optimizable is read once and cached in a temporary table (hopefully in memory) indexed
by some useful key; as each composite row percolates up out of the joined slots to the left,
a key is built from the left row and used to probe into the temporary table on the right.
+  * '''Join Strategy''' - A join strategy indicates how an optimizable joins to the optimizables
to its left in the join order. Derby currently supports two join strategies: !NestedLoop and
!HashJoin. The !NestedLoop strategy means that the whole optimizable is read for every composite
row which percolates up out of the slots to the left. The !HashJoin strategy means that the
whole optimizable is read once and cached in a temporary table (hopefully in memory) indexed
by some useful key; as each composite row percolates up out of the joined slots to the left,
a key is built from the left row and used to probe into the temporary table on the right.
   * '''Decoration''' - For each slot in a join order, the optimizer considers every possible
combination of conglomerate and join strategy. Conglomerates are only relevant for optimizables
which are tables. Join strategies are only relevant for the right slots of the join order;
the leftmost slot does not have a meaningful join strategy. A ( conglomerate, join strategy
) pair is called a decoration.
   * '''Short-circuiting''' - Most join orders are never completely evaluated. The cost of
a partial join order is always less than the cost of a more complete join order. Once the
optimizer finds the cheapest set of decorations for a partial join order, the optimizer compares
that cost to the the cheapest complete plan found so far. The optimizer abandons the whole
join order if the cheapest, partial decorated join order costs more than the cheapest complete
join order found so far.
  

Mime
View raw message