db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-766) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen
Date Thu, 22 Dec 2005 23:07:31 GMT
    [ 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


Mime
View raw message