predicates missing from the optimized tree dump

[Aakash Bordia <bo...@gmail.com>]

Hi, I was playing around with the
derby.debug.true=DumpOptimizedTreeproperty to see the optimized tree
in the
derby.log file. I found out that for a query like:
select * from  t1,t2 where  t1.c1=t2.c1;
the tree never outputs the predicate in the where clause. To workaround this
I added the printSubNodes method in FromBaseTable class like this:

 public void printSubNodes(int depth)
 {
  if (SanityManager.DEBUG)
  {
   super.printSubNodes(depth);

   if (restrictionList != null)
   {
    printLabel(depth, "restrictionList: ");
    restrictionList.treePrint(depth);
   }
  }
 }

There are several other members like nonStoreRestrictionList,
requalificationRestrictionList etc. which I do not necessarily understand,
but they are not outputted either.

I want to understand if this was intentionally left this way so that the
output does not become too long or is this something that is missing(I would
assume atleast the predicates to be dumped out).

Thanks ,Aakash

Re: predicates missing from the optimized tree dump

[Bryan Pendleton <bp...@amberpoint.com>]

> I want to understand if this was intentionally left this way so that the 
> output does not become too long or is this something that is missing(I 
> would assume atleast the predicates to be dumped out).

In a couple cases I've encountered what I felt were missing overrides
of printSubNodes myself, so my instinct is that this was an oversight,
not intentional, and would be useful functionality to add.

In general, we've been pretty liberal with the verbosity of the
tree-dumping, as it tends to be only used by the developers.

There have been periodic discussions about improving this section
of the system. The suggestion that has gathered a lot of support is
to capture the internal query plan dump output into XML format and
store it into special tables directly in the database itself, where
we could then use Derby's own XML features to process it effectively.

However, such a feature has not yet been implemented.

thanks,

bryan