On Thu, Sep 17, 2026 at 8:24 AM Nikolay Samokhvalov <[email protected]> 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
