I think I have addressed this... I would like to do these next:
- Incorporate your suggestions about comments in the code
- Add some test cases to cover cases like what you found.
- I also want to implement this optimization for InListOperator, so
that following queries can use index on REF column, if present.
- select * from t where ref in (?,?,?)
- Then I will start working on trunk to further expand the
optimzation to cover more cases.
Satheesh
Daniel John Debrunner wrote:
Satheesh Bandaram wrote:
And finally one real dumb question, in
PredicateList.pushExpressionsIntoSelect I see where you ensure the
predicate is a binary operator and has a column reference, but I can't
see where the 'don't push expressions' logic is?
By not calling pushExpressionsIntoSelect(), the code doesn't push
expressions... Where ever I find I currently can't handle the situation,
calling 'continue' in the loop skips pushing that predicate.
I don't think I was clear enough.
>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()
I don't see where predicates of the first type are distinguished from
those of the second type. I'm sure I'm being dumb and it's staring me in
the face.
In PredicateList.pushExpressionsIntoSelect I do see:
line 1418 - a comment indicating (to me) that there is logic here to
only push "simple" predicates.
line 1421 - check to see the predicate is a binary relational node
line 1425 - check to see the left is a column reference
line 1431 - see if the column is referenced in where it is being pushed to
but I don't see any code that says the right is "simple" so do push, or
the right is "complex" so don't push.
This is as much for my education on the optimizer as well as trying to
understand the patch completely.
Dan.
|
