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

I write:
>From: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
>Date: 2026-10-01 10:21
>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.a.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
>....
>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(at)qq(dot)com