Re: Can Postgres use an INDEX over an OR?
| От | Віталій Тимчишин |
|---|---|
| Тема | Re: Can Postgres use an INDEX over an OR? |
| Дата | |
| Msg-id | 331e40660907270733g4faee764oe1666d2190684c39@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Can Postgres use an INDEX over an OR? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-performance |
27 липня 2009 р. 17:18 Tom Lane <tgl@sss.pgh.pa.us> написав:
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.
Віталій Тимчишин <tivv00@gmail.com> 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.
В списке pgsql-performance по дате отправления: