> Greg Stark <[EMAIL PROTECTED]> writes:
> This approach won't get the optimizer to actually use an index for
> comparisons, but it will fix the semantics to match the spec. Later we
> either improve the optimizer to detect expressions like this (which I
> think
> would be cooler since some users may write them by hand and not use
> row-expression approach, but I don't see how to do it), or introduce a
> run-time node and have the optimizer handle it. But at least we won't
> to
> worry about backwards-compatibility issues with the semantics
> Oh, I tried to stick to the style, but sometimes I couldn't help
myself. I
> suppose I would have to fix up the style the rest of the way if I got
> working and you wanted a patch to apply.

Regarding the <= and >= operators:  can you apply them in the complex
pass? If you can, this might be more efficient.

> /*
>  * Handles something like:
>  * (A,B,C) > (X,Y,Z)
>  *
>  * By constructing something like:
>  * ( ( A > X) OR (A=X AND B>Y) OR (A=X AND B=Y AND C>Z) )
>  *                                                  ^
>  */                                                 |

the last comparison of the last major clause (or the only comparison for
a single field row construct) is a special case.  In > cases use >, in
>= cases use >=, etc.; this is logical equivalent to doing or of simple
= intersected with complex >.  

Is this step of the transformation visible to the optimizer/planner?
For purely selfish reasons, it would be really nice if a field by field
row construction could get a fast path to the index if the fields match
the index fields.


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to