> On Jul 5, 2026, at 21:36, Etsuro Fujita <[email protected]> wrote: > > Hi Chao, > > On Sat, Jul 4, 2026 at 10:24 PM Chao Li <[email protected]> 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? >
Ah, yes, that’s a leftover. Reverted that in v3. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v3-0001-Fix-ANALYZE-reporting-after-imported-foreign-tabl.patch
Description: Binary data
