> 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
