Re: [PG19][PATCH] Make postgres_fdw statistics import atomic - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: [PG19][PATCH] Make postgres_fdw statistics import atomic
Date
Msg-id CAPmGK14o862M-YQiQ4P-A1ruavM6jyFTne7HJabLdbE3bTqoEw@mail.gmail.com
Whole thread
In response to Re: [PG19][PATCH] Make postgres_fdw statistics import atomic  (Nikolay Samokhvalov <nik@postgres.ai>)
Responses Re: [PG19][PATCH] Make postgres_fdw statistics import atomic
List pgsql-hackers
On Thu, Sep 17, 2026 at 8:24 AM Nikolay Samokhvalov <nik@postgres.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



pgsql-hackers by date:

Previous
From: Dmitrii Bondar
Date:
Subject: Re: Pgbench: remove synchronous prepare
Next
From: "alvherre@kurilemu.de"
Date:
Subject: Re: Bug in logical decoding with DDL and subtransactions