Re: Use merge-based matching for MCVs in eqjoinsel
| От | David Geier |
|---|---|
| Тема | Re: Use merge-based matching for MCVs in eqjoinsel |
| Дата | |
| Msg-id | 7568e208-edf4-4b15-b033-bec5464ab75f@gmail.com обсуждение исходный текст |
| Ответ на | Re: Use merge-based matching for MCVs in eqjoinsel (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>) |
| Список | pgsql-hackers |
Hi Ilia! On 13.10.2025 12:08, Ilia Evdokimov wrote: > > On 17.09.2025 12:40, Ilia Evdokimov wrote: >> In v2 patch, when the join is reversed we pass the commutator operator >> Oid to eqjoinsel_semi(), and inside that function we immediately call >> get_opcode(<commutator operator Oid>). Did you mean for the function >> to take an operator Oid instead of an here? >> >> If that was unintentional, perhaps the cleanest fix is to add a new >> 'operator' parameter to eqjoinsel_semi() so we can keep passing >> 'opfuncoid' as before and avoid changing the behavior. >> > > This v3 patch fixes the confusion between operator and function Oids in > eqjoinsel_semi(). This version restores the previous behavior by keeping > the function Oid as before and adds an explicit 'operator' parameter so > both values are available without extra behavior changes. > > Do you have any further comments or suggestions on this version? I believe it doesn't matter. Because in try_eqjoinsel_with_hashtable() we bail if the hash function of the LHS and the RHS of the equality operator is not the same. Hence, if we use the commutator operator or not doesn't matter. But maybe I'm overlooking something. Can you provide an example that fails without your change? If you can, we could add that also to the regression tests. Beyond that everything looks good to me. The regression tests also passed for me. -- David Geier
В списке pgsql-hackers по дате отправления: