| 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
| 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 |