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 "PredicatePushdown" by Army
Date Thu, 09 Nov 2006 23:42:42 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/PredicatePushdown

------------------------------------------------------------------------------
  
  If we look again at the section entitled "A Subtlety" above, we see a case where a predicate
is pushed to two different target Optimizables depending on which join order permutation is
being evaluated. The scenario is explained in detail above, but there is one piece missing:
when we pushed the predicate to {{{ppl_info}}} as part of the 2nd call to getNextPermutation(),
we removed it from !OptimizerImpl's predicate list (see the code snippet in the preceding
section). So how were we able to push that '''same''' predicate to {{{happy_ppl_ids}}} as
part of the 4th call to getNextPermutation(), as well?
  
- The answer is pretty intuitive: between the 2nd and 4th calls to getNextPermutation(), we
"pulled" the predicate back up into the !OptimizerImpl's list of predicates. As described
on the [http://wiki.apache.org/db-derby/PredicatePushdown getNextPermutation()] page, whenever
we remove an Optimizable from the join order we also make sure that we "pull" any predicates
that were pushed to that Optimizable back up. More concretely, when we made the 3rd call to
getNextPermutation() we removed both {{{ppl_info}}} and {{{happy_ppl_ids}}} from the join
order, and then we placed {{{ppl_info}}} at the first position for the "next" permutation.
Since we had already pushed the predicate to {{{ppl_info}}} as part of the 2nd call, we pulled
it back up when we removed {{{ppl_info}}} from the join order. Thus the predicate was again
sitting in !OptimizerImpl's list of predicates and therefore we were able to push it to {{{happy_ppl_ids}}}
as part of the 4th call to getNextPermutation().
+ The answer is pretty intuitive: between the 2nd and 4th calls to getNextPermutation(), we
"pulled" the predicate back up into the !OptimizerImpl's list of predicates. As described
on the [http://wiki.apache.org/db-derby/JoinOrderPermutations getNextPermutation()] page,
whenever we remove an Optimizable from the join order we also make sure that we "pull" any
predicates that were pushed to that Optimizable back up. More concretely, when we made the
3rd call to getNextPermutation() we removed both {{{ppl_info}}} and {{{happy_ppl_ids}}} from
the join order, and then we placed {{{ppl_info}}} at the first position for the "next" permutation.
Since we had already pushed the predicate to {{{ppl_info}}} as part of the 2nd call, we pulled
it back up when we removed {{{ppl_info}}} from the join order. Thus the predicate was again
sitting in !OptimizerImpl's list of predicates and therefore we were able to push it to {{{happy_ppl_ids}}}
as part of the 4th call to getNextPermutation().
  
  To find the code that initiates the "pull" process, we look again at the getNextPermutation()
method:
  

Mime
View raw message