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

> On Jul 3, 2026, at 02:10, Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> 
> Hi Chao,
> 
> On Fri, Jun 12, 2026 at 12:49 PM Chao Li <li.evan.chao@gmail.com> wrote:
>> I think the root cause is that, with 28972b6fc, when stats are imported successfully for a foreign table, do_analyze_rel() is skipped. But do_analyze_rel() is the only place that calls pgstat_report_analyze() to update cumulative stats.
>> 
>> To fix this, I think we need to add an output parameter to ImportForeignStatistics to pass out total live rows. AFAIK, the imported remote relation stats have no dead-tuple estimate, so analyze_rel() can pass 0 as the dead-tuple estimate when calling pgstat_report_analyze(). That gives us the needed data to call pgstat_report_analyze() after a successful import.
> 
> The root-cause analysis is correct, but I don't think that the fix is
> the right way to go, because if we modified pgstat_report_analyze() to
> report more ANALYZE stats, we would need to modify the
> ImportForeignStatistics API as well, which isn't great.  To avoid
> that, how about calling pgstat_report_analyze() in
> postgresImportForeignStatistics(), like the attached?  (Actually, I
> designed the API as something we entirely replace do_analyze_rel()
> with.)  I modified the test case as well.
> 
> Sorry for the delay.
> 
> Best regards,
> Etsuro Fujita
> <Fix-ANALYZE-report-in-postgres-fdw-stat-import-efujita.patch>

Hi Etsuro-san,

Thanks for your review and for proposing an alternative fix.

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.

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

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/