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.
