From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing NOT IN to use ANTI joins |
Date: | 2014-07-02 09:44:12 |
Message-ID: | CAApHDvqE55qra8vfDvJ_0Gnw7152QM95YH1XD1enOE=T1bgFRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 2, 2014 at 9:25 PM, Jeevan Chalke <
jeevan(dot)chalke(at)enterprisedb(dot)com> wrote:
>
>
> Testing more on SQL level.
>
>
I'm just looking into an issue I've found in the find_inner_rels()
function, where it does not properly find the rel in the from list in
certain cases, for example:
explain select * from a where id not in (select b.id from b left outer join
c on b.id=c.id);
fails to use an ANTI JOIN, but if you remove the left join to c, it works
perfectly.
Currently I'm just getting my head around how the jointree is structured
and reading over deconstruct_jointree to see how it handles this. I may
change the function to find_outer_rels and just look for outer joins in the
function.
However, assigning it to author to think on above cosmetic issues.
>
>
Thanks for the review. I'll fix the issues you listed soon, but I'll likely
delay posting the updated patch until I have the other fix in place.
Regards
David Rowley
Thanks
>
> --
> Jeevan B Chalke
> Principal Software Engineer, Product Development
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip kumar | 2014-07-02 11:08:10 | Re: Selectivity estimation for inet operators |
Previous Message | Andrew Gierth | 2014-07-02 09:32:31 | Aggregate function API versus grouping sets |