From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Emre Hasegeli <emre(at)hasegeli(dot)com> |
Subject: | Re: Using each rel as both outer and inner for JOIN_ANTI |
Date: | 2021-07-01 07:09:38 |
Message-ID: | 4522921.Yh1rdoGEFm@aivenronan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Yes, thanks! I was making a big mistake here thinking the executor can
> stop after the first match. That's not true. We need to use each outer
> tuple to find all the matches and mark the corresponding hashtable
> entries. I have updated the patch with the fix.
It looks OK to me.
> > > I think we can basically use the same cost calculation as with anti
> > > joins, since they share the fact that the executor will stop after the
> > > first match. However, there are still some differences. Such as when we
> > > consider the number of tuples that will pass the basic join, I think we
> > > need to use unmatched inner rows, rather than unmatched outer rows.
> >
> > Due to the fact we cannot just skip at the first match, I'm not sure this
> > works
> > either.
>
> This is not correct any more since the fact that the executor will stop
> after the first match does not hold true. A brief thought show me that
> we can use the same cost calculation as with right joins.
Once you do that, you should also add test coverage for those new plans. Also
consider adding a commitfest entry.
Regards,
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-07-01 07:14:08 | Re: New committers: Daniel Gustafsson and John Naylor |
Previous Message | Guillaume Lelarge | 2021-07-01 07:05:58 | Re: New committers: Daniel Gustafsson and John Naylor |