Віталій Тимчишин <tivv00@gmail.com> writes: > Actually what I am talking about is to make OR with UNION (or UNION-like > because it's a little different depending on input rows uniqueness) as an > option. All of OR parts can use/not use different strategies (including > multiple different idexes or hash joins).
AFAICS you're proposing re-inventing the old implementation of OR'd indexscans. We took that out when we added bitmap scans because it didn't have any performance advantage over BitmapOr.
It's not tied to indexscans at all. Different parts can do (as in UNION) totally different strategy - e.g. perform two hash joins or perform merge join for one part and nested loop for another or ...
As of performance - see above in this thread. UNION now often provides much better performance when different parts of OR expression involve different additional tables.
