Thread: BUG #15506: Foreign data wrapper (postgres_fdw) unexpected behavior

The following bug has been logged on the website:

Bug reference:      15506
Logged by:          Timur Luchkin
Email address:      timur.luchkin@gmail.com
PostgreSQL version: 10.5
Operating system:   Ubuntu 16.04.4 LTS
Description:

I'm trying to use "use_remote_estimate = false" mode of the postgres_fdw. 
I have a very huge remote tables (several TBytes) already analyzed locally.

When I trying to analyze the foreign table itself , - it takes all the
incoming network traffic (400Mbit) and can't complete in 10 minutes (I can't
wait more, because it affects production environment). 
Why the analyze of the foreign table can't just take already collected
statistics from the remote server? Is it a bug or some limitation?

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> When I trying to analyze the foreign table itself , - it takes all the
> incoming network traffic (400Mbit) and can't complete in 10 minutes (I can't
> wait more, because it affects production environment). 
> Why the analyze of the foreign table can't just take already collected
> statistics from the remote server? Is it a bug or some limitation?

This is not a bug; it's operating as designed.

The key reason not to do it as you suggest is that whatever stats the
remote server might have for its table don't necessarily apply to the
foreign table, because the foreign table is in effect a view of the
remote table --- it could, for example, have different column types
necessitating different stats.  Or the remote server could be a different
PG version that doesn't even collect the same stats.

Another point is that ANALYZE is supposed to produce up-to-date stats,
but the remote server might not have up-to-date stats.  It's interesting
to speculate about getting around that by asking the remote server to do
an ANALYZE, but we can't assume that the local user has permissions
to do that.

There's been some discussion of providing facilities for dumping and
loading statistics, which was mainly thinking about improving pg_upgrade
but could also offer you a slightly-tedious solution for this situation.
It hasn't got past the arm-waving stage yet though.

            regards, tom lane