Re: postgres_fdw: fix cumulative stats after imported foreign-table stats - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: postgres_fdw: fix cumulative stats after imported foreign-table stats
Date
Msg-id CAPmGK17uDi89_D16UHrcct5_JwbtY_ojFtkd5gXsvJNiVJDg5Q@mail.gmail.com
Whole thread
Responses Re: postgres_fdw: fix cumulative stats after imported foreign-table stats
List pgsql-hackers
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
cumulativestats. 
>
> 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
estimatewhen calling pgstat_report_analyze(). That gives us the needed data to call pgstat_report_analyze() after a
successfulimport. 

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

Attachment

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Re-read subscription state after lock in AlterSubscription
Next
From: Heikki Linnakangas
Date:
Subject: Re: libpq: Process buffered SSL read bytes to support records >8kB on async API