Re: [PG19][PATCH] Make postgres_fdw statistics import atomic

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com
Subject: Re: [PG19][PATCH] Make postgres_fdw statistics import atomic
Date: 2026-09-23 10:21:03
Message-ID: CAPmGK14XTSDTxjNSv3FePWROyo6uNc-v2fCWCh3-R_-k95h5fQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 19, 2026 at 7:55 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> > 2. Consider whether do_analyze_rel should do something (like clear the pg_statistic rows for the relation) in the case where numrows returned from the acquirefunc is zero.
>
> I also thought this option; it would make things logically clean, but
> I'm not sure we really need to do so, because in that case we set
> reltuples=0 in pg_class, which makes the planner effectively ignore
> the remaining attribute stats. See set_baserel_size_estimates(); if
> reltuples=0, we have rel->tuples=0, so whatever value
> clauselist_selectivity() calculates/returns based on the attribute
> stats, rel->rows (the estimated number of output tuples from the base
> relation) is set to zero.

Correction: since clamp_row_est() forces a row-count estimate to be at
least one row, we have rel->rows=1, not rel->rows=0. Sorry.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2026-09-23 10:23:49 Re: [PG19][PATCH] Make postgres_fdw statistics import atomic
Previous Message Nazir Bilal Yavuz 2026-09-23 10:15:47 Re: Stabilize and shorten test_checksums/013_rewind test