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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
