> On Feb 3, 2026, at 13:39, John Naylor <[email protected]> wrote: > > To evaluate that, it would be easier if the patch were split into two > commits, one with the simple step approach, and one that changes to > the other approach. > > Also, we have some places that switch from e.g. an array to a hash > table once a collection gets above a certain threshold. In this case, > however, having less than 100 stat target is unheard of, in my > experience. It's only a tiny amount of code, but it doesn't seem worth > special-casing. Others may have a different opinion, and I'm not sure > we don't already have this behavior elsewhere.
Thanks for the suggestion — I’ve applied it in v4 by splitting the changes into two commits. 0001 contains the main optimization and uses the simpler one-step update for firstcount1 in the hash path. 0002 is a small follow-up that switches that logic to the more invariant-preserving form discussed earlier. Regarding the hash threshold: my initial approach followed existing postgres precedent for hash-based MCV matching. For example, commit 057012b205a (“Speed up eqjoinsel() with lots of MCV entries”) introduces EQJOINSEL_MCV_HASH_THRESHOLD in selfuncs.c, only enabling hashing once the MCV set is large enough to amortize the setup cost. The exact threshold differs, but the pattern is similar. Also, while 100 is the default statistics target, there are internal cases that use smaller values — e.g. vacuumdb staged analyze temporarily sets default_statistics_target to 1 and 10 in vacuuming.c — which was part of the motivation for keeping the thresholded behavior. That said, I’m happy to adjust or remove the threshold if the consensus is to simplify this further. -- Best regards, Chengpeng Yan
v4-0001-ANALYZE-speed-up-MCV-tracking-for-equality-only-t.patch
Description: v4-0001-ANALYZE-speed-up-MCV-tracking-for-equality-only-t.patch
v4-0002-ANALYZE-harden-firstcount1-tracking-in-hash-mode.patch
Description: v4-0002-ANALYZE-harden-firstcount1-tracking-in-hash-mode.patch
