> 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