Daniel John Debrunner wrote:
I don't see anything ever being removed from these hashMaps. Is it
possible to remove entries at any time?
Yes, I think it is.
My first instinct is to say that it should be possible to remove hashMap entries
once we determine that they are no longer needed. That said, there are two
types of mappings that are added to a hashMap. The first uses instances of
OptimizerImpl as the key, the second uses an optimizable query tree node (which
is an instance of Optimizable) as the key. For the latter, the key can be a
JoinNode, a UnionNode, a ProjectRestrictNode, or any other subclass of FromTable
that does not override FromTable's "optimizeIt" method.
In the first case, I think we can say that the entries are no longer needed once
the current round of optimization for the OptimizerImpl has completed. In other
words, when the call to OptimizerImpl.getNextPermutation() returns "false", the
Optimizer has finished the round of work and all "best access paths" have been
stored in the query tree nodes beneath the OptimizerImpl. So it seems to me
like that could be a good time to remove any relevant entries (meaning those
which have the OptimizerImpl as their key) from the hash maps in the query tree
nodes that make up the optimizableList.
In the second case, I think we can say that the entries are no longer needed
after the check in OptimizerImpl.getNextDecoratedPermutation() has been
performed and the appropriate action completed. In other words, after the
following if block:
// If the previous path that we considered for curOpt was _not_ the best
// path for this round, then we need to revert back to whatever the
// best plan for curOpt was this round. Note that the cost estimate
// for bestAccessPath could be null here if the last path that we
// checked was the only one possible for this round.
if ((curOpt.getBestAccessPath().getCostEstimate() != null) &&
(curOpt.getCurrentAccessPath().getCostEstimate() != null))
{
...
}
Upon completion of this "if" block the hashMap entries that are keyed on curOpt
have served their purpose (w.r.t to the subtree whose root is "curOpt") and can
probably be removed, as well.
These are the answers that come to mind with very little investigation of the
code--just based on my recollection of the code as I wrote it for DERBY-805.
Hopefully that answers your question; if not, please let me know what other info
you need.
Army
