Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match

On 8/4/26 14:29, Damil Shahzad wrote:

> Tom's concern still seems important. Scanning the whole MCV list every
> time would cost more in the common case, and it only changes the
> result when the comparison operator or collation is different from the
> equality used to build the statistics. Before this can move forward, I
> think we need a stronger reason for that tradeoff.
>
+1

A cheaper way to get some benefit here without touching that tradeoff:
when there are no MCV matches, var_eq_const does a second full pass over
MCV list just to compute `sumcommon` - but that branch is only reached
after the first loop has already scanned every entry. So `sumcommon` can
be accumulated inline in that same scan, and the separate summing loop
dropped. The match case is unaffected; only the no-match path gets
faster, by skipping a redundant second traversal.

I attached patch with these changes. What do you think?

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