27 липня 2009 р. 17:18 Tom Lane <tgl@xxxxxxxxxxxxx> написав:
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.
=?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= <tivv00@xxxxxxxxx> writes:AFAICS you're proposing re-inventing the old implementation of OR'd
> 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).
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.
