2012/10/11 Etsuro Fujita <fujita.etsuro@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 <kaigai@kaigai.gr.jp>
