[jira] Commented: (DERBY-766) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen

["Daniel John Debrunner (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-766?page=comments#action_12361153 ] 

Daniel John Debrunner commented on DERBY-766:
---------------------------------------------

I was looking at how language ResultSets are created at runtime. A UNION node will generate byte code to call this method:

	NoPutResultSet	getUnionResultSet(NoPutResultSet source1,
					NoPutResultSet source2,
					Activation activation, 
					int resultSetNumber,
					double optimizerEstimatedRowCount,
					double optimizerEstimatedCost,
					GeneratedMethod closeCleanup)

There are three interesting items here where generated code could be reduced.

1) Activation is passed into method, but it is already available to the called code from the source ResultSets (source1 or source2). Thus there is no need to pass this method in. The factory can find the activation. This technique can be used for a number of result sets, any that have a child result set.

2) The optimizer costs being passed in are rarely used, in some cases they are used as estimates for sizing items.
They are also used if the plan is displayed, to show the costs.
It's possible that the cost estimates could be saved in the saved objects structure of the plan and be available by
result set number. E.g. .store a Hashtable in the saved objects with a key of "costEstimates", the hashtable would have a key of resultSetNumber and value of a StoreCostResult.  This would also be a one time storage at compile time, rather than the current code which incurs a both a cpu and memory cost at runtime for each ResultSet and hence each active query.

3)  The closeCleanup method is passed in as null for all result sets in a tree except the top one.  Instead of passing it on each new result set, it would be much more efficient to have a setCloseMethod() that is only called once for the top result set.

Making all of these changes would result in a method signature like:

NoPutResultSet	getUnionResultSet(NoPutResultSet source1,
					NoPutResultSet source2,
						int resultSetNumber)

leading to reduced code. These techniques could obviously be applied to most of the getXXXResultSet methods in ResultSetFactory.

I'm going to be working on 1) and 3)


> Improve code generation to handle 5000 unions in a select the  union test  in largeCodeGen
> ------------------------------------------------------------------------------------------
>
>          Key: DERBY-766
>          URL: http://issues.apache.org/jira/browse/DERBY-766
>      Project: Derby
>         Type: Sub-task
>   Components: Services
>     Versions: 10.2.0.0
>     Reporter: Kathey Marsden
>      Fix For: 10.2.0.0

>
> A good incremental improvement for code generation for 10.2 would be to handle 5000 unions in the  largeCodeGen test.
> eg.   largeUnionSelect(con, viewName, 5000);
> should pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira