Army wrote: > This method is called from the "feasible()" methods of both > NestedLoopJoinStrategy.java and HashJoinStrategy.java. In the latter > case, if this method returns false, the optimizer won't ever try to do > a hash join (at least, that's how I read the code). So if we have a > subquery, in which case childResult will (or least can) be a > SelectNode, the fact that SelectNode is NOT an instance of Optimizable > means that this method will return false and the optimizer won't ever > consider a hash join when the inner table is a subquery. Is that correct?
Do you have a sample query that you can share? Is your case subqueries in Select list or subquery in WHERE clause? I thought subqueries in Select list are converted initially to FromSubQuery, which is optimizable? It would help to have a sample query to analyse. Satheesh > > According the RESOLVE in this method, this was an intentional > decision--anyone out there know why? > > The reason I ask is because I started playing around with making the > optimizer consider hash joins for subqueries, and I have made good > progress in that area. Before I go too far, though, I'm wondering > what it is that I'm missing--i.e. why was this disabled? > > Anyone know? > Army > > >
