Army wrote:
> After re-reading what I wrote, I realized we have a basis for logic to > only reset the timeout state when it could potentially be beneficial > to do so--i.e. when we have predicates pushed from the outer query. > > I could add logic to check to see if the OptimizerImpl has predicates > from outer queries and, if so, then reset the timeout state; Good plan. So in your example OI_SQ would be reoptimized by resetting the timeout only if join-predicates could come from OI_OQ? I hope we are able to correctly recognize the cases where there may be mulitple OptimizerImpl for each subquery. If there is another OI_SQ1 which may have new join-predicates this round, your changes would not reset timeout for OI_SQ? Satheesh > otherwise, since the subquery's "best plan" probably won't change much > from the previous round, we would leave the timeout state as it is. > This approach allows the optimizer to consider plans that use pushed > predicates while at the same time reducing the likelihood that queries > which have timed out in the past (prior to 10.2) would now take longer > to compile. > > I'll code that up and run derbyall tonight; in the meantime, I'd still > like to hear comments/suggestions from any readers out there... > > Thanks, > Army > > >
