db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-649) Useful indexes not used in UNION ALL
Date Fri, 16 Dec 2005 07:00:44 GMT
Satheesh Bandaram wrote:

> Daniel John Debrunner wrote:
>>>>From what I understand, your patch will push predicates like
>> a = ?
>> a = 3
>>but will not push expressions like
>> a = (1 + b)
>> a = cost(c)
>> a = rate()
> You are right... I get confused between predicates and search clauses...
> Search clauses are guaranteed to have a constant on the right, you don't
> have to check for them. But a predicate can have a non-constant
> expression on the right. I should add a check for this. *Thanks *a lot
> for catching this. BTW, I see search transitive closure optimizations
> checking for ConstantNode, but not ParameterNode. I wonder if we are
> missing some possible optimizations where a parameter marker is used,
> instead of a ConstantNode. This would could make PreparedStatements go
> slower than Statements, when most people would expect it other way. I
> will investigate and file a bug.

Wow, I'm glad I pestered. This was a useful exchange, found a bug in the
patch, I learnt something about predicates & search clauses, and
potentially it lead you to find another performance bug related to
parameters. Thanks for being patient with me.

Just quickly thinking about the checking for ConstantNode you mention, I
wonder if that is the correct approach. I thought a ValueExpression node
had a method that indicated its invariance, thus checking if a value is
statement (or query?) invariant should be used instead of it being an
instanceof ConstantNode or ParameterNode. That would mean in the future
functions that were declared deterministic on invariant values could
also be seen as constants for such optimizations. That's probably a
future cleanup, but it would be a much better approach than having these
instanceof checks.

> I will submit this small patch:

Looks good, but it leads to my next dumb question.
For these type of expressions, are they normalized so that the
column reference is always on the left? I.e. will 'a = 3' lead
to the same nodes as '3 = a'?

Not sure the patch at this point in time has to address pushing down
'3 = a' if the column reference does appear on the right in the node
tree, but I'm curious about it.


View raw message