Hi,
All the recent optimization related work on Derby inspired me to see if we can have the optimizer send information about various plans that it considered for a query into derby.log This hopefully will help debugging optimizer bugs.
After some looking through the code, it looks like there is already code which can put the optimization phase information in GenericLanguageConnectionContext if optimizer trace is turned on. For instance,
FromBaseTable.nextAccessPath calls optimizer.Trace with some tracing information. optimizer is instanceof Level2OptimizerImpl which in it's trace method checks via GenericLanguageConnectionContext.getOptimizerTrace to see if optimizer tracing is on and if yes, it puts the tracing information in a string varaible in GenericLanguageConnectionContext. The optimizer trace switch in GenericLanguageConnectionContext gets switched on by
org.apache.derby.iapi.db.OptimizerTrace's static method setOptimizerTrace. So looks like, we have the code to do the optimizer tracing but no property or any other mechanism to trun that tracing on. We can decide to introduce a new property which would be used to enable optimizer tracing. Something similar to what we do for
derby.language.logStatementText. Once Derby will detect this property, we will need to add the code to dump all the information gathered during the optimization phase into derby.log
My only concern is Derby seems to generate lot of optimizer tracing output and that can clutter derby.log
I hacked the code by hardcoding the optimizer tracing switch to true in GenericLanguageConnectionContext and adding the code to dump all the optimization information into derby.log after the optimization phase. With these change, a simple select * from t1 query (with no indexes/primary key on t1) caused
derby.log to have lot of optimization phase information in it. Attached is derby.log for this query.
Wondered what do folks think about this optimizer tracing?
Mamta
derby.log
Description: Binary data
