| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Martin Kos <martin(dot)kos(at)molecularhealth(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Bug in execution of EXISTS and IN clauses for large tables |
| Date: | 2022-02-22 23:33:19 |
| Message-ID: | CAApHDvpCKAe-7K-JfV3vYfvfTET7sjEEUFCArco3MqknmnpJYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, 23 Feb 2022 at 09:29, Martin Kos <martin(dot)kos(at)molecularhealth(dot)com> wrote:
> Just to confirm (sorry if this is a trivial question) - the "exists" and "in" should never behave like an inner join, right?
If the query planner is able first determine that the IN/EXISTs can be
executed as a semi-join, and it later can also find proofs that any
given outer side row of the semi-join can match to *at most* 1 inner
side row, then the planner will switch this to an inner join. This
allows more flexibility in the join orders, which can produce more
efficient plans.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2022-02-23 04:36:33 | BUG #17414: install failed |
| Previous Message | Mark Murawski | 2022-02-22 20:27:09 | Re: Bug plperl.c |