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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match
Date: 2026-07-30 13:39:36
Message-ID: 1034820.1785418776@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"=?utf-8?B?Wml6aHVhbkxpdSBYLU1BTg==?=" <44973863(at)qq(dot)com> writes:
> While reviewing CF6397(https://commitfest.postgresql.org/patch/6397/), I noticed that
> the function `var_eq_const()` located at `backend/utils/adt/selfuncs.c` consumes statistical
> data from the `most_common_vals` and `most_common_freqs` columns in the system
> catalog `pg_catalog.pg_stats`. Currently, the function terminates iteration immediately
> after finding the first matching entry and adopts the selectivity of this single matched value.

> I believe this estimation logic is inaccurate. Instead, we should traverse all entries in
> `most_common_vals`, check for matches against each entry, and sum up the selectivities
> of all matching items.

That would double the function's runtime on average, without changing
the results at all in most cases (it could only be different if the
given operator has different semantics from the equality operator used
while building the statistics list). I think you need a far stronger
argument for changing the existing tradeoff than "I believe".

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-07-30 13:50:54 Re: zic: fix PostgreSQL build failure on filesystems without hard link support
Previous Message Shlok Kyal 2026-07-30 12:53:04 Re: Support EXCEPT for ALL SEQUENCES publications