Mark Frost writes:
> Actually *any* most_common_elems stats would be fine, because the reasoning
> is:
> * If the searched element is in most_common_elems we know it's frequency
> * If it's not, it's less frequent than the least most_common_elems
> So in our case when every row is unique,
> On 6/5/25 17:42, Mark Frost wrote:
> > Is there any good explanation for this behaviour? Preferably we’d like
> > some way for proper `most_common_elems` statistics to be collected in
> > our production database, in the hope that influences a good query plan
> > to always be selected.
> most_c
On 6/5/25 23:52, Tom Lane wrote:
The idea of treating lack of MCELEM differently from complete
lack of stats still seems to have merit, though.
Couldn't we count / estimate the number of distinct two-by-two elements,
and use that instead of the default selectivity estimate?
