Re: postgres_fdw: fix cumulative stats after imported foreign-table stats

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>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: Re: postgres_fdw: fix cumulative stats after imported foreign-table stats
Date: 2026-07-06 04:36:08
Message-ID: CAPmGK17n6vKYa6q+ap+cLD-NpDby+s0mRh0SRc+XgiWbqWSd1Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Chao,

On Sat, Jul 4, 2026 at 10:24 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> I thought postgres_fdw was where we interact with the remote server, while analyze_rel() is the code deciding that ANALYZE succeeded. Ideally, cumulative ANALYZE reporting would be driven from that level, not from an FDW callback implementation.

The division of labor would be arbitrary: as mentioned upthread, the
FDW callback is designed as a function corresponding to
do_analyze_rel(), which not only updates the stats system catalogs but
reports to pgstats, so I think it's appropriate for the callback to do
the report as well.

> But I understand your concern about changing the ImportForeignStatistics API, so I’m fine with your proposal. I have integrated your changes into v2.

Ok, thanks for the integration!

@@ -230,7 +230,8 @@ analyze_rel(Oid relid, RangeVar *relation,
if (fdwroutine->ImportForeignStatistics != NULL &&
fdwroutine->ImportForeignStatistics(onerel, va_cols, elevel))
stats_imported = true;
- else
+
+ if (!stats_imported)

Is this a leftover?

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-07-06 04:54:26 Re: Re-read subscription state after lock in AlterSubscription
Previous Message Tom Lane 2026-07-06 04:26:54 Re: Add malloc attribute to memory allocation functions