Re: postgres_fdw: fix cumulative stats after imported foreign-table stats
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Corey Huinker <corey.huinker@gmail.com>
Date: 2026-07-03T09:10:36Z
Lists: pgsql-hackers
Attachments
- Fix-ANALYZE-report-in-postgres-fdw-stat-import-efujita.patch (application/octet-stream) patch
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