I wrote:
>> How about getting # of rows estimate by executing EXPLAIN for
>> fully-fledged remote query (IOW, contains pushed-down WHERE clause),
and
>> estimate selectivity of local filter on the basis of the statistics
>> which are generated by FDW via do_analyze_rel() and FDW-specific
>> sampling function? In this design, we would be able to use quite
>> correct rows estimate because we can consider filtering stuffs done
on
>> each side separately, though it requires expensive remote EXPLAIN for
>> each possible path.
>
> That sounds nice.
... but it still suffers from the problems of local statistics
for remote tables I pointed out.
I think that these shortcomings are not justified by the gain of
one client-server round trip less during planning. I'd prefer
if pgsql_fdw were not dependent on remote statistics stored in the
local database.
Yours,
Laurenz Albe