Re: pgsql_fdw, FDW for PostgreSQL server
От | Etsuro Fujita |
---|---|
Тема | Re: pgsql_fdw, FDW for PostgreSQL server |
Дата | |
Msg-id | 4ECF5189.2060203@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: pgsql_fdw, FDW for PostgreSQL server (Shigeru Hanada <shigeru.hanada@gmail.com>) |
Ответы |
Re: pgsql_fdw, FDW for PostgreSQL server
|
Список | pgsql-hackers |
Hi Hanada-san, (2011/11/16 1:55), Shigeru Hanada wrote: > Attached are revised version of pgsql_fdw patches. I'm still under reviewing, so the following is not all. I'm sorry. estimate_costs() have been implemented to ask a remote postgres server for the result of EXPLAIN for a remote query to get its costs such as startup_cost and total_cost. I think this approach is the most accurate way to get its costs. However, I think it would be rather costly. And I'm afraid of that it might work only for pgsql_fdw. Because, even if we are able to obtain such a cost information by EXPLAINing a remote query at a remote server where a DBMS different from postgres runs, it might be difficult to incorporate such a cost information with the postgres cost model due to their possible inconsistency that such a cost information provided by the EXPLAIN command in the other DBMS might have different meanings (or different scales) from that provided by the EXPLAIN command in postgres. So, I think it might be better to estimate such costs by pgsql_fdw itself without EXPLAINing on the assumption that a remote postgres server has the same abilities for query optimization, which is less costly and widely applicable to the other DBMSs, while it, of course, only works once we have statistics and/or index information for foreign tables. But AFAIK we eventually want to have those, so I'd like to propose to use the proposed approach until that time. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: