[ http://issues.apache.org/jira/browse/DERBY-808?page=all ]
Satheesh Bandaram updated DERBY-808:
------------------------------------
Summary: PreparedStatements can take longer to execute than Statements.
There seem to be a problem with searchClauseTransitiveClosure method in
PredicateList.java (was: PreparedStatements can take longer to execute than
Statements. There seem to be two problems with searchClauseTransitiveClosure
method in PredicateList.java)
Description:
PreparedStatements could take much longer than Statements because of incorrect
search clause transitive closure optimization. For the customer case I
investigated this problem, Statement would complete in about 13 seconds, where
as equivalent PreparedStatement ran "forever". (stoped it after hours)
I think there a problem with PredicateList.searchClauseTransitiveClosure
method. This method tries to add new search clauses based on equality join
between tables involved. Current code only looks for ConstantNodes on the
right side of searchClauses. This would miss ParameterNodes, so Derby might
miss search clause transitive closure optimizations for PreparedStatements.
was:
PreparedStatements could take much longer than Statements because of incorrect
search clause transitive closure optimization. For the customer case I
investigated this problem, Statement would complete in about 13 seconds, where
as equivalent PreparedStatement ran "forever". (stoped it after hours)
I think there are two (minor) issues with
PredicateList.searchClauseTransitiveClosure method. This method tries to add
new search clauses based on equality join between tables involved. The issues
are:
1) Current code only looks for ConstantNodes on the right side of
searchClauses. This would miss ParameterNodes, so Derby might miss search
clause transitive closure optimizations for PreparedStatements.
2) Minor coding error:
if (left instanceof ColumnReference && right instanceof ConstantNode)
{
searchClauses.addElement(predicate);
}
else if (right instanceof ConstantNode && left instanceof ColumnReference)
{
// put the ColumnReference on the left to simplify things
bcon.swapOperands();
searchClauses.addElement(predicate);
}
The second part of the check is incorrect. It should instead be like:
else if (left instanceof ConstantNode && right instanceof ColumnReference)
and while handling ParameterNodes.
Breaking up this issue into two tasks. I would like fix for first task to go
into 10.1.2 and 10.2.
> PreparedStatements can take longer to execute than Statements. There seem to
> be a problem with searchClauseTransitiveClosure method in PredicateList.java
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-808
> URL: http://issues.apache.org/jira/browse/DERBY-808
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.1.2.0, 10.2.0.0
> Environment: generic
> Reporter: Satheesh Bandaram
> Fix For: 10.2.0.0, 10.1.3.0
>
> PreparedStatements could take much longer than Statements because of
> incorrect search clause transitive closure optimization. For the customer
> case I investigated this problem, Statement would complete in about 13
> seconds, where as equivalent PreparedStatement ran "forever". (stoped it
> after hours)
> I think there a problem with PredicateList.searchClauseTransitiveClosure
> method. This method tries to add new search clauses based on equality join
> between tables involved. Current code only looks for ConstantNodes on the
> right side of searchClauses. This would miss ParameterNodes, so Derby might
> miss search clause transitive closure optimizations for PreparedStatements.
--
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
