Re: Using each rel as both outer and inner for JOIN_ANTI

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

In response to

Responses

Browse pgsql-hackers by date

  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