From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimization for updating foreign tables in Postgres FDW |
Date: | 2016-02-23 06:18:30 |
Message-ID: | 56CBF9B6.3070308@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/02/22 20:13, Rushabh Lathia wrote:
> I did another round of review for the latest patch and well as performed
> the sanity test, and
> haven't found any functional issues. Found couple of issue, see in-line
> comments
> for the same.
Thanks!
> On Thu, Feb 18, 2016 at 3:15 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>> wrote:
>
> On 2016/02/12 21:19, Etsuro Fujita wrote:
> + /* Check point 1 */
> + if (operation == CMD_INSERT)
> + return false;
> +
> + /* Check point 2 */
> + if (nodeTag(subplan) != T_ForeignScan)
> + return false;
> +
> + /* Check point 3 */
> + if (subplan->qual != NIL)
> + return false;
> +
> + /* Check point 4 */
> + if (operation == CMD_UPDATE)
>
> These comments are referring to something in the function header
> further up, but you could instead just delete the stuff from the
> header and mention the actual conditions here.
> Will fix.
> Done.
>
> The patch doesn't allow the postgres_fdw to push down an
> UPDATE/DELETE on a foreign join, so I added one more condition here
> not to handle such cases. (I'm planning to propose a patch to
> handle such cases, in the next CF.)
> I think we should place the checking foreign join condition before the
> target columns, as foreign join condition is less costly then the target
> columns.
Agreed.
> Other changes:
> * I keep Rushabh's code change that we call PlanDMLPushdown only
> when all the required APIs are available with FDW, but for
> CheckValidResultRel, I left the code as-is (no changes to that
> function), to match the docs saying that the FDW needs to provide
> the DML pushdown callback functions together with existing
> table-updating functions such as ExecForeignInsert,
> ExecForeignUpdate and ExecForeignDelete.
> I think we should also update the CheckValidResultRel(), because even
> though ExecForeignInsert,
> ExecForeignUpdate and ExecForeignDelete not present, FDW still can perform
> UPDATE/DELETE/INSERT using DML Pushdown APIs. Lets take committer's view
> on this.
OK
> PFA update patch, which includes changes into postgresPlanDMLPushdown()
> to check for join
> condition before target columns and also fixed couple of whitespace issues.
Thanks again for updating the patch and fixing the issues!
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-02-23 07:17:36 | Password identifiers, protocol aging and SCRAM protocol |
Previous Message | Tom Lane | 2016-02-23 06:17:29 | Re: postgres_fdw vs. force_parallel_mode on ppc |