Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match
Date
Msg-id 1034820.1785418776@sss.pgh.pa.us
Whole thread
Responses Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match
Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match
List pgsql-hackers
"=?utf-8?B?Wml6aHVhbkxpdSBYLU1BTg==?=" <44973863@qq.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



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Fix hashchar() and hashcharextended() to not depend on char signedness
Next
From: David K
Date:
Subject: Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)