Horton
Menu

Re: Hash-based MCV matching for large IN-lists

Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>

View thread
From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Tatsuya Kawata <kawatatatsuya0913@gmail.com>, David Geier <geidav.pg@gmail.com>, Chengpeng Yan <chengpeng_yan@outlook.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-26T08:57:26Z
Lists: 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/

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Short-circuit row estimation in NOT IN containing NULL consts