Re: Update comments in functions for statistics import in postgres_fdw.c

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Update comments in functions for statistics import in postgres_fdw.c
Date: 2026-11-10 09:50:02
Message-ID: CAPmGK15N1fHWn8+kNSUCoHo6+XQvviUenHy_YckbRUZpcf_6dg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 10, 2026 at 3:23 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> ```
> + /*
> + * ATTSTATS_NUM_FIELDS corresponds to the number of statistical value
> + * parameters for import_attribute_statistics(), which is larger than that
> + * for import_relation_statistics(). Therefore, a NullableDatum array of
> + * that length is used to store data for each parameter in both functions.
> + */
> NullableDatum args[ATTSTATS_NUM_FIELDS];
> ```
>
> I think this comment is slightly inaccurate. ATTSTATS_NUM_FIELDS is 14, including ATTSTATS_ATTNAME as 0. So the number of statistical value parameters is 13. import_attribute_statistics() needs 14 NullableDatatum including a “version” argument plus 13 statistical value parameters.

As I understand it, you are saying we need to separate the version
parameter from statistical value parameters, but the comment for
import_attribute_statistics says:

* Import attribute statistics from NullableDatum inputs for all statistical
* values.
*
* For now, the 'version' argument is ignored. In the future it can be used
* to interpret older statistics properly.

So IMU I think we are using the term "statistical value parameters" to
include the version parameter. With that in mind, what I proposed is
not that bad...

Thanks for reviewing!

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-11-10 09:59:39 Re: Incorrect CONTEXT reported for errors from parallel apply worker in logical replication
Previous Message Xuneng Zhou 2026-11-10 09:25:47 Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE