From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Shigeru HANADA *EXTERN*" <shigeru(dot)hanada(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Kohei KaiGai" <kaigai(at)kaigai(dot)gr(dot)jp>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> |
Subject: | Re: pgsql_fdw, FDW for PostgreSQL server |
Date: | 2012-03-28 07:18:36 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C207AA8DA3@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2012-03-28 07:35:11 | Re: Multiple Slave Failover with PITR |
Previous Message | Thom Brown | 2012-03-28 07:13:29 | Re: pgsql_fdw, FDW for PostgreSQL server |