Re: pgsql_fdw, FDW for PostgreSQL server

Albe Laurenz <laurenz.albe@wien.gv.at>

From: "Albe Laurenz" <laurenz.albe@wien.gv.at>
To: "Albe Laurenz" <laurenz.albe@wien.gv.at>, "Shigeru HANADA *EXTERN*" <shigeru.hanada@gmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Kevin Grittner" <Kevin.Grittner@wicourts.gov>, "Robert Haas" <robertmhaas@gmail.com>, "PostgreSQL-development" <pgsql-hackers@postgresql.org>, "Kohei KaiGai" <kaigai@kaigai.gr.jp>, "Martijn van Oosterhout" <kleptog@svana.org>, "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>, "Hitoshi Harada" <umi.tanuki@gmail.com>
Date: 2012-03-28T07:18:36Z
Lists: pgsql-hackers
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