Re: Optimize MCV stats for sortable types and utilize sorted-order properties

From: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, tgl <tgl(at)sss(dot)pgh(dot)pa(dot)us>, tomas <tomas(at)vondra(dot)me>, dean(dot)a(dot)rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, guofenglinux <guofenglinux(at)gmail(dot)com>
Subject: Re: Optimize MCV stats for sortable types and utilize sorted-order properties
Date: 2026-09-30 13:34:24
Message-ID: tencent_6EA1365FDAD9899A6F2C4B2BEAC5C660F807@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

1. Update the pg_stats_ext_exprs view to expose STATISTIC_KIND_MCV_VALUE_SORTED
through most_common_vals and most_common_freqs.

2. Regarding pg_statistic_get_difference():

The input statistics can come either from pg_stats or directly from the user.
I initially considered improving the detection of the stat kind during import,
but there are several considerations and implementation difficulties.
For now, I think it is better to keep the existing logic.

* Adding a stat kind parameter would rely on the caller to make the correct decision,
and would also affect quite a few interfaces.
* Another idea is to inspect most_common_vals and most_common_freqs during import,
sort them if possible, and generate STATISTIC_KIND_MCV_VALUE_SORTED; otherwise,
keep STATISTIC_KIND_MCV.

I looked into the latter, but it seems more complicated than expected because both inputs are text.
We would need to deserialize them into the actual data type, sort them, and serialize them again.
I have not worked out the details yet. If anyone is familiar with this part of the code and has suggestions,
I would be happy to investigate further.

3. I think pg_statistic_get_difference() could also have stronger validation in the future.

For input from pg_stats, the core code has already processed the statistics, so for STATISTIC_KIND_MCV,
most_common_freqs[0] is the maximum and most_common_freqs[n - 1] is the minimum.

For user-provided input, however, there is currently no such restriction. We only perform basic checks,
such as array lengths and NULLs. We could consider strengthening these checks in the future.

regards,
--
ZizhuanLiu (X-MAN) 
44973863(at)qq(dot)com

Attachment Content-Type Size
v7-0001-Optimize-MCV-statistics-for-sortable-types.patch application/octet-stream 65.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-09-30 13:40:21 Re: BUG #19686: Rolling back SET TABLESPACE
Previous Message Nisha Moond 2026-09-30 13:22:55 Re: Proposal: Conflict log history table for Logical Replication