You are viewing a plain text version of this content. The canonical link for it is here.

Posted to derby-user@db.apache.org by Paul Davern <pd...@4c.ucc.ie> on 2013/11/05 15:44:48 UTC

Execution tree metadata

Hello

I am looking at monitoring/tracing the resultset execution tree to
observe the tuples/records as they propagate up the tree - specifically
the calls to getNextRowCore() in BulkTableScanResultSet,
NestedLoopJoinResultSet, etc. For aggregations  I am looking at using the
SortObserver type interface.

There does not appear to be much in the way of metadata available (at
least I have not found it) in the execution tree? I am traversing the AST
tree after bind/generate to pick up some of the metadata. This is easy
enough when a column is directly associated with a base table, but, is
getting hacky otherwise. Is there a better solution? Putting something in
during the generate phase looks like a daunting task!

I realise I can use the  toXML/childrenToXML interface  to walk the
execution tree, but there does not appear to be much in the way of
metadata here.

I suppose what I am asking is, is there a direct link from the 
org.apache.derby.impl.sql.execute.ResultSet hierarchy back to the
org.apache.derby.impl.sql.compile.ResultSetNode hierarchy?


Thanks,
Paul.

Re: Execution tree metadata

Posted by Paul Davern <pd...@4c.ucc.ie>.

Thanks Rick,
I already looked at the ResultSet.getResultDescription(), but obviously
not enough.

Paul.
> Hi Paul,
>
> Some comments inline...
>
> On 11/5/13 6:44 AM, Paul Davern wrote:
>> Hello
>>
>> I am looking at monitoring/tracing the resultset execution tree to
>> observe the tuples/records as they propagate up the tree - specifically
>> the calls to getNextRowCore() in BulkTableScanResultSet,
>> NestedLoopJoinResultSet, etc. For aggregations  I am looking at using
>> the
>> SortObserver type interface.
>>
>> There does not appear to be much in the way of metadata available (at
>> least I have not found it) in the execution tree? I am traversing the
>> AST
>> tree after bind/generate to pick up some of the metadata. This is easy
>> enough when a column is directly associated with a base table, but, is
>> getting hacky otherwise. Is there a better solution? Putting something
>> in
>> during the generate phase looks like a daunting task!
> Not sure what metadata you are looking for. But the following may be
> useful: The execution plan is a tree of
> org.apache.derby.iapi.sql.ResultSet nodes. The row signature of each
> node can be obtained by calling ResultSet.getResultDescription().
>> I realise I can use the  toXML/childrenToXML interface  to walk the
>> execution tree, but there does not appear to be much in the way of
>> metadata here.
> Thanks for raising this issue. It would be good to be able to plug
> custom xml-formatters into those methods. I have logged an enhancement
> request for this: https://issues.apache.org/jira/browse/DERBY-6404
>
> In the meantime, if I were tackling this problem, I would hack the
> toXML/childrenToXML methods to grab the metadata you need. For an
> example of how to invoke toXML(), see
> org.apache.derbyTesting.functionTests.tests.lang.NewOptimizerOverridesTest.getLastQueryPlan().
>
> Hope this helps,
> -Rick
>> I suppose what I am asking is, is there a direct link from the
>> org.apache.derby.impl.sql.execute.ResultSet hierarchy back to the
>> org.apache.derby.impl.sql.compile.ResultSetNode hierarchy?
>>
>>
>> Thanks,
>> Paul.
>>
>>
>
>
>

Re: Execution tree metadata

Posted by Rick Hillegas <ri...@oracle.com>.

Hi Paul,

Some comments inline...

On 11/5/13 6:44 AM, Paul Davern wrote:
> Hello
>
> I am looking at “monitoring/tracing” the resultset execution tree to
> observe the tuples/records as they propagate up the tree - specifically
> the calls to getNextRowCore() in BulkTableScanResultSet,
> NestedLoopJoinResultSet, etc. For aggregations  I am looking at using the
> SortObserver type interface.
>
> There does not appear to be much in the way of metadata available (at
> least I have not found it) in the execution tree? I am traversing the AST
> tree after bind/generate to pick up some of the metadata. This is easy
> enough when a column is directly associated with a base table, but, is
> getting hacky otherwise. Is there a better solution? Putting something in
> during the generate phase looks like a daunting task!
Not sure what metadata you are looking for. But the following may be 
useful: The execution plan is a tree of 
org.apache.derby.iapi.sql.ResultSet nodes. The row signature of each 
node can be obtained by calling ResultSet.getResultDescription().
> I realise I can use the  toXML/childrenToXML interface  to walk the
> execution tree, but there does not appear to be much in the way of
> metadata here.
Thanks for raising this issue. It would be good to be able to plug 
custom xml-formatters into those methods. I have logged an enhancement 
request for this: https://issues.apache.org/jira/browse/DERBY-6404

In the meantime, if I were tackling this problem, I would hack the 
toXML/childrenToXML methods to grab the metadata you need. For an 
example of how to invoke toXML(), see 
org.apache.derbyTesting.functionTests.tests.lang.NewOptimizerOverridesTest.getLastQueryPlan().

Hope this helps,
-Rick
> I suppose what I am asking is, is there a direct link from the
> org.apache.derby.impl.sql.execute.ResultSet hierarchy back to the
> org.apache.derby.impl.sql.compile.ResultSetNode hierarchy?
>
>
> Thanks,
> Paul.
>
>