Re: [BUG?] estimate_hash_bucket_stats uses wrong ndistinct for avgfreq
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Joel Jacobson" <joel@compiler.org>
Cc: "Tender Wang" <tndrwang@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-01T00:08:05Z
Lists: pgsql-hackers
"Joel Jacobson" <joel@compiler.org> writes: > On Fri, Feb 27, 2026, at 20:15, Tom Lane wrote: >> Joel, do you want to run this to ground, and in particular >> see if that way of fixing it passes your sanity tests? > Challenge accepted! Thanks! > [...hours later...] > My conclusion is that we still need to move avgfreq > computation, like I suggested. Hmm ... doesn't this contradict your argument that avgfreq and mcv_freq need to be calculated on the same basis? Admittedly that was just a heuristic, but I'm not seeing why it's wrong. > The reason for this is that estfract is calculated as: > estfract = 1.0 / ndistinct; > where ndistinct has been adjusted to account for restriction clauses. > Therefore, we must also use the adjusted avgfreq when adjusting > estfract here: It feels like that might end up double-counting the effects of the restriction clauses. Anyway, we all seem to agree that s/rel->rows/rel->tuples/ is the correct fix for a newly-introduced bug. I'm inclined to proceed by committing that fix (along with any regression test fallout) and then investigating the avgfreq change as an independent matter. regards, tom lane
Commits
-
Fix estimate_hash_bucket_stats's correction for skewed data.
- e6a1d8f5acbc 19 (unreleased) landed
-
Correctly calculate "MCV frequency" for a unique column.
- d80b0225010f 19 (unreleased) landed