From: | "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | "'Shigeru HANADA'" <shigeru(dot)hanada(at)gmail(dot)com>, "'Kohei KaiGai'" <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FDW for PostgreSQL |
Date: | 2012-10-11 09:10:58 |
Message-ID: | 003001cda790$53b989d0$fb2c9d70$@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
As an example, the FDW might identify some restriction clauses of the form
foreign_variable= sub_expression, which it determines can be executed on the
remote server given the locally-evaluated value of the sub_expression. The
actual identification of such a clause should happen during GetForeignPaths,
since it would affect the cost estimate for the path.
Thanks,
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2012-10-11 09:19:34 | Re: replace plugins directory with GUC |
Previous Message | Simon Riggs | 2012-10-11 08:57:28 | Re: change in LOCK behavior |