I wrote: >> Changes from previous version >> ============================= >> >> 1) Don't use remote EXPLAIN for cost/rows estimation, so now planner >> estimates result rows and costs on the basis of local statistics such >> as pg_class and pg_statistic. To update local statistics, I added >> pgsql_fdw_analyze() SQL function which updates local statistics of a >> foreign table by retrieving remote statistics, such as pg_class and >> pg_statistic, via libpq. This would make the planning of pgsql_fdw >> simple and fast. This function can be easily modified to handle >> ANALYZE command invoked for a foreign table (Fujita-san is proposing >> this as common feature in another thread).
> I see the advantage of being able to do all this locally, but > I think there are a lot of downsides too: I found another limitation of this approach: pgsql_fdw_analyze() has to run as a user who can update pg_statistic, and this user needs a user mapping to a remote user who can read pg_statistic. This is not necessary for normal operation and needs to be configured specifically for getting remote statistics. This is cumbersome, and people might be unhappy to have to create user mappings for highly privileged remote users. 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
