db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Re: [OPTIMIZER] Optimizer "timeout" for subqueries?
Date Fri, 03 Mar 2006 18:51:28 GMT
Satheesh Bandaram wrote:

> Good plan. So in your example OI_SQ would be reoptimized by resetting
> the timeout only if join-predicates could come from OI_OQ? 

Only if join predicates *came* from OI_OQ, yes.  I don't think "could come" 
would be the right approach because then we might reset the timeout state even 
though there aren't actually any predicates this round.  It's possible the 
predicate will be pushed for one round and not pushed for another, and we would 
only want to reset the timeout when the predicate was actually pushed.

> If there is another OI_SQ1 which may have new join-predicates this round, 
> your changes would not reset timeout for OI_SQ?

If OI_OQ is pushing a predicate down, it will only push it to the subquery to 
which it is intened--either OI_SQ1 or OI_SQ2.  The predicate will then be scoped 
to that subquery and passed into the that subquery's OptimizerImpl.  The 
OptimizerImpl will in turn see the scoped predicate and reset its timeout state. 
  The OptimizerImpl for the other subquery will _not_ have received the 
predicate and so it will not reset its state.

Extending my original example to be:

select <...> from
   (select t1.i, t2.j from t1, t2 where <...>) X1,
   (select t3.a, t4.b from t3, t4 where <...>) X2,
where T5.p = X2.a

Then we'd have OI_OQ for the outer select, OI_SQ1 for X1 and OI_SQ2 for X2.  In 
this case OI_OQ would only pass the predicate to OI_SQ2 since that's the target 
subquery of the reference "X2.a".  So OI_SQ2 would reset its timeout state. 
OI_SQ1 would not.

All of that said, my changes for DERBY-805 won't actually push the predicate in 
the above example--DERBY-805 will only push predicates into UNION nodes.  But 
the argument is still the same...

Does that answer your question?

View raw message