Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: Mark Frost <FROSTMAR(at)uk(dot)ibm(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column
Date: 2025-06-05 17:09:06
Message-ID: 3e539c8b-c95a-4ba9-8462-04045b2da2b0@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mahdi Bahrami 2025-06-05 18:25:04 Re: Database creation performance drop going from pg 14 to pg 15+
Previous Message Mark Frost 2025-06-05 15:42:00 Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column