I write:
>From: ZizhuanLiu X-MAN <44973863@qq.com>
>Date: 2026-10-01 10:21
>To: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
>Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, tgl <tgl@sss.pgh.pa.us>, tomas <tomas@vondra.me>, dean.a.rasheed
<dean.a.rasheed@gmail.com>,guofenglinux <guofenglinux@gmail.com>
>Subject: Re: Optimize MCV stats for sortable types and utilize sorted-order properties
>....
>Sorry, there was a mistake in my previous message.
>The function I meant was pg_restore_attribute_stats(), not pg_statistic_get_difference().
>
>pg_restore_extended_stats() has the same issue:
>it always uses STATISTIC_KIND_MCV and does not check whether most_common_freqs[0] is the maximum frequency
>and most_common_freqs[n - 1] is the minimum frequency.
>
>One possible solution is to add an optional mcv_kind parameter to these two functions,
>with the default value being STATISTIC_KIND_MCV.
>
>This allows existing callers to keep the current behavior, while callers that provide
>STATISTIC_KIND_MCV_VALUE_SORTED statistics can explicitly preserve the correct statistics kind.
>
>This should minimize the impact on existing interfaces. Comments and suggestions are welcome.
Hi,
Add an optional most_common_vals_kind parameter to pg_restore_attribute_stats()
and the expr arguments of pg_restore_extended_stats() to specify whether most_common_vals[]
and most_common_freqs[] are of type 1-STATISTIC_KIND_MCV or 8-STATISTIC_KIND_MCV_VALUE_SORTED.
If the parameter is not specified, it defaults to 1-STATISTIC_KIND_MCV, preserving the existing behavior.
The corresponding test SQL and test results are attached.
regards,
--
ZizhuanLiu (X-MAN)
44973863@qq.com
