You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by Apache Wiki <wi...@apache.org> on 2009/04/11 21:19:49 UTC

[Db-derby Wiki] Trivial Update of "QueryPlanJoinOrder" by BryanPendleton

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 BryanPendleton:
http://wiki.apache.org/db-derby/QueryPlanJoinOrder

The comment on the change is:
Capture useful suggestion from Mamta

------------------------------------------------------------------------------
  
  This page was compiled with information posted to the derby-dev mailing list by Manjula, Kathey, Army and Knut.
  
+ == Controlling Join Order in a test situation ==
+ 
+ Sometimes, it can be convenient to control the join order. For example, when debugging a problem, it can be useful to force the optimizer to consider only a particular join order. In [https://issues.apache.org/jira/browse/DERBY-3926 DERBY-3926] such a case arose, and Mamta noted that it was useful to control the Optimizer's behavior using query overrides:
+ 
+ {{{
+ SELECT table1.id, m0.value, m1.value FROM --DERBY-PROPERTIES joinOrder=FIXED
+ table2 m1 -- DERBY-PROPERTIES index=key3
+ , table2 m0 -- DERBY-PROPERTIES index=key3
+ , table1
+ WHERE table1.id=m0.id AND m0.name='PageSequenceId' AND table1.id=m1.id AND m1.name='PostComponentId' AND m1.value='21857' ORDER BY m0.value;
+ }}}
+ 
+ By controlling the join order, you may be able to get a simple repro case (ie you don't have to go through countless iteration of optimizer for all different join orders and different predicate pulling down in different join orders), which may make it easier to focus on the problem join order.
+