public inbox for [email protected]
help / color / mirror / Atom feedFrom: Frédéric Yhuel <[email protected]>
To: Mark Frost <[email protected]>
To: [email protected] <[email protected]>
Subject: Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column
Date: Thu, 5 Jun 2025 19:09:06 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <PH3PPF1C905D6E6F24A5C1A1A1D8345B593E16FA@PH3PPF1C905D6E6.namprd15.prod.outlook.com>
References: <PH3PPF1C905D6E6F24A5C1A1A1D8345B593E16FA@PH3PPF1C905D6E6.namprd15.prod.outlook.com>
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.
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox