| From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
|---|---|
| To: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, 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-17 11:12:54 |
| Message-ID: | CAPmGK14o862M-YQiQ4P-A1ruavM6jyFTne7HJabLdbE3bTqoEw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 17, 2026 at 8:24 AM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
> Thanks Corey. Shouldn't an empty fallback preserve the old
> pg_statistic rows, as analyze normally does?
I don't think so, because if the fallback sample is empty, we have
reltuples=0 in pg_class, meaning that any attribute stats are
effectively ignored in planning.
Also, I think the scenario you showed upthread is not supported, or at
least not recommended:
* You declared the type of a column of the foreign table differently
from the remote table, but that isn't recommended, as noted in the
documentation: "It is generally recommended that the columns of a
foreign table be declared with exactly the same data types, and
collations if applicable, as the referenced columns of the remote
table..."
* You imported remote stats without re-analyzing the remote table
after the delete operation, but that isn't supported, as noted in the
documentation; "When using this option, it is the user's
responsibility to ensure that the existing statistics for the remote
table are up-to-date."
And I think any surprising behavior arising from such a use is the
user's fault rather than the system's fault.
Thanks for the testing!
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | alvherre@kurilemu.de | 2026-09-17 11:16:04 | Re: Bug in logical decoding with DDL and subtransactions |
| Previous Message | Dmitrii Bondar | 2026-09-17 11:06:27 | Re: Pgbench: remove synchronous prepare |