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