Обсуждение: Hash-based MCV matching for large IN-lists

Hi hackers,

When estimating selectivity for ScalarArrayOpExpr (IN, ANY, ALL) and MCV statistics are available for the column, the planner currently matches IN-list elements against the MCV array using nested loop. For large IN-list and large MCV arrays this results in O(N*M) behavior, which can become unnecessarily expensive during planning.

Thanks to David for pointing out this case [0]

This patch introduces a hash-based matching path, analogous to what is already done for MCV matching in join selectivity estimation (057012b commit). Instead of linearly scanning the MCV array for each IN-list element, we build a hash table and probe it to identify matches.

The hash table is built over the MCV values, not over the IN-list. The IN-list may contain NULLs, non-Const expressions, and duplicate values, whereas the MCV list is guaranteed to contain distinct, non-NULL values and represents the statistically meaningful domain we are matching against. Hashing the MCVs therefore avoids duplicate work and directly supports selectivity estimation.

For each IN-list element, if a matching MCV is found, we add the corresponding MCV frequency to the selectivity estimate. If no match is found, the remaining selectivity is estimated in the same way as the existing non-MCV path (similar to var_eq_const when the constant is not present in the MCV list).

The hash-based path is enabled only when both a sufficiently large IN-list and an MCV list are present, and suitable hash functions exist for the equality operator. The threshold is currently the same as the one used for join MCV hashing, since the underlying algorithmic tradeoffs are similar.

Example:

CREATE TABLE t (x int);
INSERT INTO t SELECT x % 10000 FROM generate_series(1, 3000000) x;
ALTER TABLE t ALTER COLUMN x SET STATISTICS 10000;
ANALYZE t;

Before patch:
EXPLAIN (SUMMARY) SELECT * FROM t WHERE x IN (1,2,...,2000);
Seq Scan on t  (cost=5.00..58280.00 rows=600000 width=4)
   Filter: (x = ANY ('{1,2,...,2000}'::integer[]))
 Planning Time: 57.137 ms
(3 rows)

After patch:
EXPLAIN (SUMMARY) SELECT * FROM t WHERE x IN (1,2,...,2000);
Seq Scan on t  (cost=5.00..58280.00 rows=600000 width=4)
   Filter: (x = ANY ('{1,2,...,2000}'::integer[]))
 Planning Time: 0.558 ms
(3 rows)

Comments, suggestions, and alternative approaches are welcome!

[0]: https://www.postgresql.org/message-id/b6316b99-565b-4c89-aa08-6aea51f54526%40gmail.com

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

Hi Ilia!

On 29.12.2025 21:35, Ilia Evdokimov wrote:
> Hi hackers,
> 
> When estimating selectivity for ScalarArrayOpExpr (IN, ANY, ALL) and MCV
> statistics are available for the column, the planner currently matches
> IN-list elements against the MCV array using nested loop. For large IN-
> list and large MCV arrays this results in O(N*M) behavior, which can
> become unnecessarily expensive during planning.
> 
> Thanks to David for pointing out this case [0]
> 

Cool that you tackled this. I've seen this happening a lot in practice.

> This patch introduces a hash-based matching path, analogous to what is
> already done for MCV matching in join selectivity estimation (057012b
> commit). Instead of linearly scanning the MCV array for each IN-list
> element, we build a hash table and probe it to identify matches.
> 
> The hash table is built over the MCV values, not over the IN-list. The
> IN-list may contain NULLs, non-Const expressions, and duplicate values,
> whereas the MCV list is guaranteed to contain distinct, non-NULL values
> and represents the statistically meaningful domain we are matching
> against. Hashing the MCVs therefore avoids duplicate work and directly
> supports selectivity estimation.

The downside of doing it this way is that we always pay the price of
building a possibly big hash table if the column has a lot of MCVs, even
for small IN lists. Why can't we build the hash table always on the
smaller list, like we do already in the join selectivity estimation?

For NULL we can add a flag to the hash entry, non-Const expressions must
anyways be evaluated and duplicate values will be discarded during insert.

> 
> For each IN-list element, if a matching MCV is found, we add the
> corresponding MCV frequency to the selectivity estimate. If no match is
> found, the remaining selectivity is estimated in the same way as the
> existing non-MCV path (similar to var_eq_const when the constant is not
> present in the MCV list).
> 

The code in master currently calls an operator-specific selectivity
estimation function. For equality this is typically eqsel() but the
function can be specified during CREATE OPERATOR.

Can be safely special-case the behavior of eqsel() for all possible
operators for the ScalarArrayOpExpr case?

> The hash-based path is enabled only when both a sufficiently large IN-
> list and an MCV list are present, and suitable hash functions exist for
> the equality operator. The threshold is currently the same as the one
> used for join MCV hashing, since the underlying algorithmic tradeoffs
> are similar.

Seems reasonable.

I'll test and review in more detail once we clarified the design.

--
David Geier

Hi David!

Thanks for feedback.

This patch introduces a hash-based matching path, analogous to what is
already done for MCV matching in join selectivity estimation (057012b
commit). Instead of linearly scanning the MCV array for each IN-list
element, we build a hash table and probe it to identify matches.

The hash table is built over the MCV values, not over the IN-list. The
IN-list may contain NULLs, non-Const expressions, and duplicate values,
whereas the MCV list is guaranteed to contain distinct, non-NULL values
and represents the statistically meaningful domain we are matching
against. Hashing the MCVs therefore avoids duplicate work and directly
supports selectivity estimation.

The downside of doing it this way is that we always pay the price of
building a possibly big hash table if the column has a lot of MCVs, even
for small IN lists. Why can't we build the hash table always on the
smaller list, like we do already in the join selectivity estimation?

For NULL we can add a flag to the hash entry, non-Const expressions must
anyways be evaluated and duplicate values will be discarded during insert.

After thinking more about this I realized that this is actually a better match for how selectivity is currently modeled. After this comments in master

         * If we were being really tense we would try to confirm that the
         * elements are all distinct, but that would be expensive and it
         * doesn't seem to be worth the cycles; it would amount to penalizing
         * well-written queries in favor of poorly-written ones.  However, we
         * do protect ourselves a little bit by checking whether the
         * disjointness assumption leads to an impossible (out of range)
         * probability; if so, we fall back to the normal calculation.

when the hash table is built on the IN-list, duplicate IN-list values are automatically eliminated during insertion, so we no longer risk summing the same MCV frequency multiple times. This makes the disjoint-probability estimate more robust and in practice slightly more accurate.

One thing I initially missed that there are actually three different places where ScalarArrayOpExpr is handled - the Const array case, the ArrayExpr case and others - and Const and ArrayExpr require different implementation of the same idea. In Const case we can directly hash and probe Datum value, while ArrayExpr case we must work on Node* element, separating constant and non-constant entries and only hashing the constants. The current v2 therefore applies the same MCV-hash optimization in both branches, but using two tailored code paths that preserve the existing semantics of how non-Const elements are handled by var_eq_non_const().

If the MCV list is smaller than the IN-list, the behavior is the same as in v1 of the patch. If the IN-list is smaller, we instead build a hash table over the distinct constant elements of the IN-list and then:
- Scan the MCV list and sum the frequencies of those MCVs that appear in the IN-list;
- Count how many distinct IN-list not null constant elements are not present in the MCV list;
- Estimate the probability of each such non-MCV value using the remaining frequency mass;
- Handle non-constant IN-list elements separately using var_eq_non_const(), exactly as in the existing implementation.

For each IN-list element, if a matching MCV is found, we add the
corresponding MCV frequency to the selectivity estimate. If no match is
found, the remaining selectivity is estimated in the same way as the
existing non-MCV path (similar to var_eq_const when the constant is not
present in the MCV list).

The code in master currently calls an operator-specific selectivity
estimation function. For equality this is typically eqsel() but the
function can be specified during CREATE OPERATOR.

Can be safely special-case the behavior of eqsel() for all possible
operators for the ScalarArrayOpExpr case?

Unfortunately there is no safe way to make this optimization generic for arbitrary restrict functions, because a custom RESTRICT function does not have to use MCVs at all. IMO, in practice the vast majority of ScalarArrayOpExpr uses with = or <> rely on the built-in equality operators whose selectivity is computed by eqsel()/neqsel(), so I limited this optimization to those cases.

I’ve attached v2 of the patch. It currently uses two fairly large helper functions for the Const and ArrayExpr cases; this is intentional to keep the logic explicit and reviewable, even though these will likely need refactoring or consolidation later.

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

On 14.01.2026 11:19, Ilia Evdokimov wrote:
> After thinking more about this I realized that this is actually a better
> match for how selectivity is currently modeled. After this comments in
> master
> 
>          * If we were being really tense we would try to confirm that the
>          * elements are all distinct, but that would be expensive and it
>          * doesn't seem to be worth the cycles; it would amount to
> penalizing
>          * well-written queries in favor of poorly-written ones.
> However, we
>          * do protect ourselves a little bit by checking whether the
>          * disjointness assumption leads to an impossible (out of range)
>          * probability; if so, we fall back to the normal calculation.
> 
> when the hash table is built on the IN-list, duplicate IN-list values
> are automatically eliminated during insertion, so we no longer risk
> summing the same MCV frequency multiple times. This makes the disjoint-
> probability estimate more robust and in practice slightly more accurate.

Does that mean that we get a different estimation result, depending on
if the IN list is smaller or not? I think we should avoid that because
estimation quality might flip for the user unexpectedly.

> One thing I initially missed that there are actually three different
> places where ScalarArrayOpExpr is handled - the Const array case, the
> ArrayExpr case and others - and Const and ArrayExpr require different
> implementation of the same idea. In Const case we can directly hash and
> probe Datum value, while ArrayExpr case we must work on Node* element,
> separating constant and non-constant entries and only hashing the
> constants. The current v2 therefore applies the same MCV-hash
> optimization in both branches, but using two tailored code paths that
> preserve the existing semantics of how non-Const elements are handled by
> var_eq_non_const().
> 
> If the MCV list is smaller than the IN-list, the behavior is the same as
> in v1 of the patch. If the IN-list is smaller, we instead build a hash
> table over the distinct constant elements of the IN-list and then:
> - Scan the MCV list and sum the frequencies of those MCVs that appear in
> the IN-list;
> - Count how many distinct IN-list not null constant elements are not
> present in the MCV list;

Is this to make sure we keep getting the same estimation result if the
IN list is smaller and contains duplicates?

> - Estimate the probability of each such non-MCV value using the
> remaining frequency mass;
> - Handle non-constant IN-list elements separately using
> var_eq_non_const(), exactly as in the existing implementation.

OK

>>>
>> The code in master currently calls an operator-specific selectivity
>> estimation function. For equality this is typically eqsel() but the
>> function can be specified during CREATE OPERATOR.
>>
>> Can be safely special-case the behavior of eqsel() for all possible
>> operators for the ScalarArrayOpExpr case?
> 
> 
> Unfortunately there is no safe way to make this optimization generic for
> arbitrary restrict functions, because a custom RESTRICT function does
> not have to use MCVs at all. IMO, in practice the vast majority of
> ScalarArrayOpExpr uses with = or <> rely on the built-in equality
> operators whose selectivity is computed by eqsel()/neqsel(), so I
> limited this optimization to those cases.

How did you do that? I cannot find the code that checks for that.

> I’ve attached v2 of the patch. It currently uses two fairly large helper
> functions for the Const and ArrayExpr cases; this is intentional to keep
> the logic explicit and reviewable, even though these will likely need
> refactoring or consolidation later.

Beyond that, it seems like you can also combine/reuse a bunch of code
for creating the hash map on the IN vs on the MCV list.

For the MCVs, can't we reuse some code from the eqjoinsel() optimization
we did? The entry and context structs look similar enough to only need one.

Making the code more compact would ease reviewing a lot.

--
David Geier

Hi,

Does that mean that we get a different estimation result, depending on
if the IN list is smaller or not? I think we should avoid that because
estimation quality might flip for the user unexpectedly.

I think you're right.

To address this, I changed the hash-table entry to track an additional 'count' filed, representing how many times a particular value appears on the hashed side. When inserting into the hash table, if the value is already present, I increment 'count', otherwise, I create a new entry with count = 1

The code in master currently calls an operator-specific selectivity
estimation function. For equality this is typically eqsel() but the
function can be specified during CREATE OPERATOR.

Can be safely special-case the behavior of eqsel() for all possible
operators for the ScalarArrayOpExpr case?

Unfortunately there is no safe way to make this optimization generic for
arbitrary restrict functions, because a custom RESTRICT function does
not have to use MCVs at all. IMO, in practice the vast majority of
ScalarArrayOpExpr uses with = or <> rely on the built-in equality
operators whose selectivity is computed by eqsel()/neqsel(), so I
limited this optimization to those cases.

How did you do that? I cannot find the code that checks for that.

In scalararraysel(), before attempting the hash-based path, we determine whether the operator behaves like equality or inequality based on its selectivity function:

if (oprsel == F_EQSEL || oprsel == F_EQJOINSEL)
    isEquality = true;
else if (oprsel == F_NEQSEL || oprsel == F_NEQJOINSEL)
    isInequality = true;

Then the hash-based MCV matching is only attempted under:

if ((isEquality || isInequality) && !is_join_clause)

So effectively this restricts the optimization to operators whose selectivity is computed by eqsel()/neqsel() on restriction clauses. Join clauses (which would use eqjoinsel/neqjoinsel) are excluded via !is_join_clause

For the MCVs, can't we reuse some code from the eqjoinsel() optimization
we did? The entry and context structs look similar enough to only need one.

I considered reusing pieces from the eqjoinsel() , but in practice it turned out to be difficult to share code cleanly. Also, when looking at this file more broadly, we already have multiple places that reimplement similar pattern.

Making the code more compact would ease reviewing a lot.

Agreed — I also think making the code more compact would significantly ease reviewing. I’ve found a way to unify the Const-array and ArrayExpr cases: in the ArrayExpr path, we can first construct the same arrays as in the Const-array case (elem_values, elem_nulls), and additionally build a boolean array elem_const[] indicating whether each element is a Const. Then the hash-based MCV matching function can:

- Ignore NULL and non-Const elements when building and probing the hash table.
- Count how many non-Const elements are present.
- After MCV and non-MCV constant handling, account for non-Const elements separately using var_eq_non_const() and fold their probabilities into the same ANY/ALL accumulation logic.

I've attached v3 patch with it.

To validate the same estimation results, I temporarily kept both implementations (hash-based and nested-loop) and compared their resulting selectivity values. Whenever they differed, I logged it. I ran regression tests and some local workload testing with this check enabled, and did not observe any mismatches. I attached patch with this logging.

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

> On Jan 14, 2026, at 18:19, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com> wrote:
> I’ve attached v2 of the patch. It currently uses two fairly large helper functions for the Const and ArrayExpr cases;
thisis intentional to keep the logic explicit and reviewable, even though these will likely need refactoring or
consolidationlater.
 

Thanks for working on this.

I had previously reviewed the v2 patch and wrote up some comments, but
didn’t get a chance to send them before v3 was posted. I haven’t yet had
time to review v3 in detail, so I’m not sure whether the issues below
have already been addressed there. I’m posting my earlier review notes
first and will follow up with comments on v3 once I’ve had a chance to
look at it.

* Treat NULL array elements as zero selectivity for ALL:

In `scalararray_mcv_hash_match_const()` (and similarly
`scalararray_mcv_hash_match_expr()`), NULL array elements are currently
handled by simply continuing the loop (e.g. `if (elem_nulls[i])
continue;`), effectively ignoring them.

This behavior is only correct for ANY/OR semantics. For ALL/AND (`useOr
= false`), a single NULL array element causes the `ScalarArrayOpExpr` to
never return TRUE for strict operators (as assumed by the surrounding
code and comments). In that case, the correct selectivity estimate
should be 0.0, but the current code path can return a non-zero
selectivity.


* Fix cross-type equality argument order in `mcvs_in_equal`:

`mcvs_in_equal()` always invokes the equality function as `(key0,
key1)`. However, `simplehash` provides `key0` from the hash table and
`key1` as the probe key.

In the branch where the hash table is built over IN-list values and
probed with MCVs (the `sslot.nvalues > num_elems` path), this reverses
the operator’s argument order for cross-type equality operators. This
risks incorrect match decisions and may misinterpret Datums compared to
the operator’s declared signature.


* Include non-MCV IN-list constants in non-disjoint selectivity:

In the `sslot.nvalues > num_elems` path of
`scalararray_mcv_hash_match_const()` and
`scalararray_mcv_hash_match_expr()`, non-MCV constant elements currently
only contribute via `disjoint_sel`.

For cases where disjoint-probability estimation is not used (e.g. ALL,
`<> ANY`, or when `disjoint_sel` is out of range), the code leaves the
selectivity based solely on MCV matches. This effectively treats non-MCV
constants as having probability 1.0, leading to overestimation of
selectivity.


* Avoid double-negating inequality estimates for non-Const elements:

In the `scalararray_mcv_hash_match_expr()` `sslot.nvalues > num_elems`
branch, non-Const elements are handled via

`var_eq_non_const(..., negate = isInequality)`

and then later adjusted again with

`if (isInequality)
s1 = 1.0 - s1 - nullfrac;`

This results in a double negation for inequality cases, effectively
turning the estimate back into an equality selectivity.

--
Best regards,
Chengpeng Yan

Hi Chengpeng,

Thanks for your review!

* Treat NULL array elements as zero selectivity for ALL:

Agreed. For ALL/AND semantics the function now returns selectivity = 0.0 as soon as a NULL element is encountered.

* Fix cross-type equality argument order in `mcvs_in_equal`:

Agreed. Added 'op_is_reserved' flag MCVInHashContext, same as in MCVHashContext.

* Include non-MCV IN-list constants in non-disjoint selectivity:

This is not applicable to v3.

* Avoid double-negating inequality estimates for non-Const elements:

Agreed. var_eq_non_const() is now always with negate = false, not to call negation twice.

Attached v4 patch with above fixes.

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

Hi!

> Attached v4 patch with above fixes.

Good progress!

I did another pass over the code, focusing on structure:

- MCVHasContext and MCVInHashContext are identical. MCVHashEntry and
MCVInHashEntry only differ by the count member. I would, as said before,
merge them and simply not use the count member for the join case.

- hash_mcv_in() and mcvs_in_equal() are identical to hash_mcv() and
mcvs_equal(). Let's remove the new functions and use the existing ones
instead, in the spirit of the previous point.

- The threshold constants are also identical. I would merge them into a
single, e.g. MCV_HASH_THRESHOLD, in the spirit of the previous two points.

- MCVHashTable_hash will then be interchangable with
MCVInHashTable_hash. So let's remove MCVInHashTable_hash, in the spirit
of the previous three points.

- Use palloc_array() instead of palloc() when allocating arrays.

- We can avoid allocating the all-true elem_const array by passing NULL
for elem_const to scalararray_mcv_hash_match(), and considering a NULL
pointer to mean "all elements are constant".

- The following comment got copy&pasted from eqsel_internal() twice. It
reads a little strange now because we're not punting here by immediately
returning like in eqsel_internal() but instead fallback to the original
code path. Maybe say instead "... falling back to default code path to
compute default selectivity" or something like that.
    /*
     * If expression is not variable = something or something =
     * variable, then punt and return a default estimate.
     */

- The call to fmgr_info(opfuncoid, &eqproc) is currently under have_mcvs
but can be moved into the next if.

- elem_nulls and elem_const does have to be 0-initialized via palloc0().
All elements are set in the subsequent for-loop. I believe elem_values
also doesn't have to be 0-initialized via palloc0().

- Have you checked there there's test coverage for the special cases
(nvalues_non_mcv > 0, nvalues_nonconst > 0, IN contains NULL,
isEnequality==true, etc.)?  If not let's add tests for these.


I'll do a 2nd iteration, focusing on correctness, once these comments
are addressed and I've got the SQL from you so that I can test the
corner cases manually.

--
David Geier

I've fixed all the comments raised above and updated the v5 patch.


On 2/7/26 10:42, Tatsuya Kawata wrote:
> I initially considered consolidating this by checking for NULL 
> elements before building the hash table, but realized this would add 
> an extra loop in the common case where there are no NULLs.

Thanks for that suggestion. We can check for NULL elements without an 
explicit loop by using memchr(), so there's no need for an additional 
building of hash table. I'll update patch with it.

That said, I think it might be better to continue this small 
optimization with NULL for constant arrays separately in another thread. 
It's cleaner to split this work into smaller, focused changes rather 
than mixing everything into single patch


If anything is still unclear in the code or insufficiently documented, 
or if you have other suggestions, please do not hesitate to point them out.

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

> That said, I think it might be better to continue this small
> optimization with NULL for constant arrays separately in another thread.
> It's cleaner to split this work into smaller, focused changes rather
> than mixing everything into single patch

Given that there's now a new thread about this, let's either remove it
from this patch and make sure we rebase correctly once the other patch
is merged, or use the latest version from this patch (ARR_HASNULL()
instead of memchr()).

> If anything is still unclear in the code or insufficiently documented,
> or if you have other suggestions, please do not hesitate to point them out.

- Currently we bail for unique Vars, via the following line.
var_eq_const() returns 1.0 / vardata->rel->tuples in that case. How
about we improve this case as well and, either, return
number_of_in_elements / vardata->rel->tuples, or fill the hash map and
then return number_of_unique_in_elements / vardata->rel->tuples. In
master this code is currently O(n). We could make it O(1) and keep the
today's semantics (count duplicates), or keep it O(n) but improve it by
not counting duplicates.

  if (vardata->isunique && vardata->rel && vardata->rel->tuples >= 1.0)
      return -1.0;

- How about factoring out the shared code from accum_scalararray_prob()
which is also used in the original estimation implementation? That would
get rid of some code duplication. Not sure how nice the code will get
though.

- The comment starting with the following line seems to have unintended
line breaks in various places (between the enumeration items):

  Build arrays describing ARRAY[] elements:

- No need to use palloc0_array() for elem_values as all elements are
initialized anyways.

- Use lfirst_node() and castNode() instead of C type casts.

- Add a comment to the following line where you bail because an element
is NULL for the NOT IN case.

  if (!useOr && elem_nulls[i])

- You can use foreach_current_index(). Then you don't need to declare
and update your own loop counter.

The rest looks good to me.

--
David Geier

Hi, thanks for working on this!

On Wed Feb 18, 2026 at 9:48 AM -03, Ilia Evdokimov wrote:
> I've fixed all the comments raised above and updated the v5 patch.
>

Here are some comments regarding v5 patch:

On scalararraysel() we have:

+                ReleaseVariableStats(vardata);
+
+                if (s1 >= 0.0)
+                    return s1;

I'm wondering if we also should call ReleaseVariableStats() on the early
return?

+                    if (!useOr && elem_nulls[i])
+                    {
+                        pfree(elem_values);
+                        pfree(elem_nulls);
+                        pfree(elem_const);
+
+                        return (Selectivity) 0.0;
+                    }

------------------

On scalararray_mcv_hash_match() free_attstatsslot() is called only on
if (have_mcvs && OidIsValid(hashLeft) && OidIsValid(hashRight)),
perhaps it should be moved outside the if condition?

+    if (have_mcvs && OidIsValid(hashLeft) && OidIsValid(hashRight))
+    {
+       ...

+        MCVHashTable_destroy(hashTable);
+        free_attstatsslot(&sslot);
+    }
+
+    return selec;


------------------

typo: "all elements are const"

+ *              array is NULL if all elemnets is const.

------------------

It's worth adding on scalararray_mcv_hash_match() an early return when
num_elems == 0? I imagine that this can happens, e.g "WHERE a =
ANY(array[]::int[]);". In this case the function should still execute
completely?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

Hello

+ hashContext.hash_fcinfo = hash_fcinfo;
+ hashContext.op_is_reversed = !hash_mcv;
+ hashContext.insert_mode = true;

Are you sure about op_is_reversed, isn't it backwards, shouldn't it be
= hash_mcv instead?

See the following testcase:

CREATE TABLE test_cross_type_bug (val float4);

INSERT INTO test_cross_type_bug
    SELECT v
      FROM generate_series(1, 200) AS v,
           generate_series(1, 50);

ALTER TABLE test_cross_type_bug ALTER COLUMN val SET STATISTICS 200;
ANALYZE test_cross_type_bug;

SELECT string_agg(v::text, ', ') AS in_list
  FROM generate_series(1, 200) AS gs(v) \gset

EXPLAIN SELECT * FROM test_cross_type_bug
 WHERE val = ANY(ARRAY[:in_list]::float4[]);

EXPLAIN SELECT * FROM test_cross_type_bug
 WHERE val = ANY(ARRAY[:in_list]::float8[]);

DROP TABLE test_cross_type_bug;

I've addressed the review comments mentioned above.

David made a very good observation: for unique columns, where each iteration effectively returns the same per-element selectivity, there is no need to iterate at all. In such cases we can reduce the computation to a closed-form expression, i.e. O(1) instead of running the loop O(N).

I applied this idea to unique columns and cases falling back to DEFAULT_EQ_SEL. In both cases the loop can be replaced with a closed-from formula implemented in calculate_combined_selectivity(). The formula mirros the existing independent/disjoint probability model: ANY (sel = 1 - (1 - s) ^ length or length * s ), ALL (sel = s ^ length or 1 - length*(1 - s)). It would be good to carefully review that this is fully equivalent to the current accumulation logic.

I also exprimented with applying the same idea to elements that are not found in MCV, are not Const, and effectively found in MCV with more than one count. Those cases can still be accumulated using accum_scalararray_prob(), but potentially grouped to reduce repeated work.

Overall, the optimization work can be logically split into three parts:

1. Degenerate NULL case O(N) -> O(1) [0]
2. Identical non-NULL per-element selectivity O(N) -> O(1) (can be split into a separate thread if prederred)
3. MCV matching via hashing O(M*N) -> O(M+N) (current thread)

Feedback on how to best structure or split this work would be appreciated.

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.

Thoughts?

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

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/