Re: Import Statistics in postgres_fdw before resorting to sampling.

On Fri, Jan 16, 2026 at 11:49 AM Corey Huinker <corey.huinker@gmail.com>
wrote:

> Assuming following conditions to be true
>> 1. object on the other side usually has statistics
>> 2. it didn't when we queried.
>>
>> The reason for that situation is that the object was not analyzed
>> before for the reasons you mention. Then why not just run ANALYZE and
>> instantiate the statistics. That will happen only rarely.
>
>
> I agree.
>
>
>> Why do we
>> need a table and server option to control that behaviour? Maybe you
>> have already explained and I am not able to understand your answer.
>>
>
> I probably didn't explain it, but one reason for having the option is that
> the role used to connect to the remote database might not have the
> permissions to analyze tables in general, or that table in particular.
>

Changes in this release, aside from rebasing:

- The generic analyze and fdw.h changes are in their own patch (0001) that
ignores contrib/postgres_fdw entirely.
- The option for remote_analyze has been moved to its own patch (0003).
- The errors raised are now warnings, to ensure that we can always fall
back to row sampling.
- All local attributes with attstatarget > 0 must get matching remote
statistics or the import is considered a failure.
- The pg_restore_attribute_stats() call has been turned into a prepared
statement, for clarity and some minor parsing savings.
- The calls to pg_restore_relation_stats() are parameterized, but not
prepared as this is rarely called more than once.
- postgresStatisticsAreImportable will now disqualify a table if has
extended statistics objects, because we can't compute those without a row
sample.