This would appear to indicate that the optimizer is rejecting a NestedLoopJoinStrategy because the table is too big (i.e. larger than the 1MB default).
The logic to reject a join strategy that uses too much memory is in OptimizerImpl.costBasedCostOptimizable(). It gives an estimated number of rows per scan to optimizable.memoryUsage(), which gives an estimated memory usage per row and a row count to joinStrategy.memoryUsage(). The implementation of memoryUsage() in HashJoinStrategy returns the product of the two numbers, while the implementation in NestedLoopJoinStrategy returns a constant 0.0. So, the estimated memory usage for a nested loop is always zero, while for a hash join it's based on the width of the rows and the estimated number of rows.
Back in OptimizerImpl.costBasedCostOptimizable(), it rejects any join strategy that would use more memory than maxMemoryPerTable. Since this is always zero for nested loops, it doesn't ever reject a nested loop for this reason.
- Jeff Lichtman
[EMAIL PROTECTED]
Check out Swazoo Koolak's Web Jukebox at
http://swazoo.com/
