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 по дате отправления: