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 Tue, 08 Aug 2006 21:15:28 GMT
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.


View raw message