Daniel John Debrunner wrote:
Any pointers to the type of extra state kept around. Is it query tree
nodes, collections, something else?
With Phase 1 of DERBY-805, a HashMap was added to each query tree node. The map
holds an Object->AccessPathImpl mapping for each OptimizerImpl that occurs above
the node in the query tree. The "Object" in this mapping is an object that
already existed; the AccessPathImpl is a new object.
See FromTable.addOrLoadBestPlanMapping()
With Phase 4, additional entries to the HashMap are added for every UnionNode,
PRN, or JoinNode that occurs above the node...and also for every occurrence of a
node that doesn't implement "optimizeIt()". *Ouch*. After writing that, I find
myself feeling rather ill.
The comments around these additional calls explain why they are there:
// It's possible that a call to optimize the [ node ] will cause
// a new "truly the best" plan to be stored in the underlying base
// tables. If that happens and then we decide to skip that plan
// (which we might do if the call to "considerCost()" below decides
// the current path is infeasible or not the best) we need to be
// able to revert back to the "truly the best" plans that we had
// saved before we got here. So with this next call we save the
// current plans using "this" node as the key. If needed, we'll
// then make the call to revert the plans in OptimizerImpl's
// getNextDecoratedPermutation() method.
Army
