2012/10/11 Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>: > Hi Hanada-san, > >> Please examine attached v2 patch (note that is should be applied onto >> latest dblink_fdw_validator patch). > > I've reviewed your patch quickly. I noticed that the patch has been created > in > a slightly different way from the guidelines: > http://www.postgresql.org/docs/devel/static/fdw-planning.html The guidelines > say the following, but the patch identifies the clauses in > baserel->baserestrictinfo in GetForeignRelSize, not GetForeignPaths. Also, it > has been implemented so that most sub_expressions are evaluated at the remote > end, not the local end, though I'm missing something. For postgresql_fdw to > be > a good reference for FDW developers, ISTM it would be better that it be > consistent with the guidelines. I think it would be needed to update the > following document or redesign the function to be consistent with the > following > document. > Hmm. It seems to me Fujita-san's comment is right.
Even though the latest implementation gets an estimated number of rows using EXPLAIN with qualified SELECT statement on remote side, then, it is adjusted with selectivity of local qualifiers, we shall be able to obtain same cost estimation because postgresql_fdw assumes all the pushed-down qualifiers are built-in only. So, is it available to move classifyConditions() to pgsqlGetForeignPlan(), then, separate remote qualifiers and local ones here? If we call get_remote_estimate() without WHERE clause, remote side will give just whole number of rows of remote table. Then, it can be adjusted with selectivity of "all" the RestrictInfo (including both remote and local). Sorry, I should suggest it at the beginning. This change may affects the optimization that obtains remote columns being in-use at local side. Let me suggest an expression walker that sets member of BitmapSet for columns in-use at local side or target list. Then, we can list up them on the target list of the remote query. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
