| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Hamilton <thomashamilton76(at)yahoo(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Automatic optimization of IN clauses via INNER JOIN |
| Date: | 2009-12-19 00:22:29 |
| Message-ID: | 603c8f070912181622l2d74d0cdq94390eb1b1911729@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
2009/12/18 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
> 2009/12/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> 2009/12/18 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
>>> On Fri, Dec 18, 2009 at 2:18 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>
>>>> NOT IN is the only that really kills you as far as optimization is
>>>> concerned. IN can be transformed to a join. NOT IN forces a NOT
>>>> (subplan)-type plan, which bites - hard.
>>>
>>> in a well designed database (read: not abusing NULLs) - it can be done
>>> with joins too.
>>
>> But not by PostgreSQL, or so I believe.
>
> using left join ?
If at least one column in the subselect is strict, you can rewrite it
that way yourself, but the optimizer won't do it. I wish it did, but I
don't wish it badly enough to have written the code myself, and
apparently neither does anyone else.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-12-19 00:24:31 | Re: Issues with \copy from file |
| Previous Message | Greg Stark | 2009-12-18 17:29:15 | Re: Idea how to get rid of Bitmap Heap Scan |