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
