Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column
Frédéric Yhuel <frederic.yhuel@dalibo.com>
From: Frédéric Yhuel <frederic.yhuel@dalibo.com>
To: Mark Frost <FROSTMAR@uk.ibm.com>,
"pgsql-performance@lists.postgresql.org"
<pgsql-performance@lists.postgresql.org>
Date: 2025-06-05T17:09:06Z
Lists: pgsql-performance
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_common_elems has a limited size, and if all the elements have the same freq, there's nothing we can do. You could do: alter table test alter column tags set statistics X; However, X is capped at 10000, which means that the size of most_common_elems will be less than 100k, and it would probably be stupid to go beyond that anyway. It seems that postgres lacks some kind of "n_distinct_elems" for that kind of case, but let's wait and see what the statistics gurus think.
Commits
-
Track the maximum possible frequency of non-MCE array elements.
- 261f89a976bf 19 (unreleased) landed
-
Collect and use element-frequency statistics for arrays.
- 0e5e167aaea4 9.2.0 cited