db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@gmail.com>
Subject Re: [jira] Commented: (DERBY-1315) largeCodeGen fails with embedded and framework DerbyNetClient
Date Wed, 09 Aug 2006 03:06:47 GMT
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.


View raw message