Re: Hash-based MCV matching for large IN-lists - Mailing list pgsql-hackers

From Ilia Evdokimov
Subject Re: Hash-based MCV matching for large IN-lists
Date
Msg-id bc73f8dc-07ab-499e-b36d-8fc8c98faa13@tantorlabs.com
Whole thread Raw
In response to Re: Hash-based MCV matching for large IN-lists  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
Responses Re: Hash-based MCV matching for large IN-lists
List pgsql-hackers
On 2/26/26 01:45, Ilia Evdokimov wrote:

> About op_is_reserved. It seems we should assign op_is_reserved = true, 
> because we don't reverse types like eqjoinsel_semi(). If IN-list 
> smaller than MCV-list we reverse it by fmgr_info(hash_mcv ? hashLeft : 
> hashRight, &hash_proc). Thanks for this remark.
>
I guess I rushed to conclusions. This assignment op_is_reversed = true 
was incorrect. During lookups, simplehash passes: key0 as the value 
stored in the hash table, key1 as the probe value. Since MCV entries 
correspond to the variable's statistics, the correct argument order 
depends on which side we build the hash table on. If we hash MCV values 
(hash_mcv = true), then key0 = MCV value, key1 = IN-list value, so we 
must call operator(key0, key1). If we hash IN-list elements (hash_mcv = 
fasle), then key0 = IN-list value, key1 = MCV value and we must call 
operator(key1, key0). Therefore the correct assignment is 
hashContext.op_is_reversed = hash_mcv.

If you have another suggestions to v6 patches, send them, and I'll fix 
them with hashContext.op_is_reversed = hash_mcv.

-- 
Best regards,
Ilia Evdokimov,
Tantor Labs LLC,
https://tantorlabs.com/




pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: DOCS - Add introductory paragraph to Getting Started chapter
Next
From: Ashutosh Sharma
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication