Re: Push down more UPDATEs/DELETEs in postgres_fdw - Mailing list pgsql-hackers

From Rushabh Lathia
Subject Re: Push down more UPDATEs/DELETEs in postgres_fdw
Date
Msg-id CAGPqQf0JDmKnS50EBFUKoAtp-6nXJ3KkUkuCMip3bmujBAwEmw@mail.gmail.com
Whole thread Raw
In response to Re: Push down more UPDATEs/DELETEs in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Push down more UPDATEs/DELETEs in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Thanks Fujita-san for working on this. I've signed up to review this patch.

Your latest patch doesn't not get apply cleanly apply on master branch.

patching file contrib/postgres_fdw/deparse.c
6 out of 17 hunks FAILED -- saving rejects to file contrib/postgres_fdw/deparse.c.rej
patching file contrib/postgres_fdw/expected/postgres_fdw.out
2 out of 2 hunks FAILED -- saving rejects to file contrib/postgres_fdw/expected/postgres_fdw.out.rej
patching file contrib/postgres_fdw/postgres_fdw.c
2 out of 22 hunks FAILED -- saving rejects to file contrib/postgres_fdw/postgres_fdw.c.rej
patching file contrib/postgres_fdw/postgres_fdw.h
1 out of 3 hunks FAILED -- saving rejects to file contrib/postgres_fdw/postgres_fdw.h.rej

Please share the patch which get apply clean on master branch.



On Fri, Nov 11, 2016 at 5:00 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
On 2016/09/08 19:55, Etsuro Fujita wrote:
On 2016/09/07 13:21, Ashutosh Bapat wrote:
    * with the patch:
    postgres=# explain verbose delete from ft1 using ft2 where ft1.a =
    ft2.a;
                                                             QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------------

     Delete on public.ft1  (cost=100.00..102.04 rows=1 width=38)
       ->  Foreign Delete  (cost=100.00..102.04 rows=1 width=38)
             Remote SQL: DELETE FROM public.t1 r1 USING (SELECT ROW(a,
    b), a FROM public.t2) ss1(c1, c2) WHERE ((r1.a = ss1.c2))
    (3 rows)

The underlying scan on t2 requires ROW(a,b) for locking the row for
update/share. But clearly it's not required if the full query is being
pushed down.

Is there a way we can detect that ROW(a,b) is useless
column (not used anywhere in the other parts of the query like
RETURNING, DELETE clause etc.) and eliminate it?

I don't have a clear solution for that yet, but I'll try to remove that
in the next version.

Similarly for a, it's
part of the targetlist of the underlying scan so that the WHERE clause
can be applied on it. But it's not needed if we are pushing down the
query. If we eliminate the targetlist of the query, we could construct a
remote query without having subquery in it, making it more readable.

Will try to do so also.

I addressed this by improving the deparse logic so that a remote query for performing an UPDATE/DELETE on a join directly on the remote can be created as proposed if possible.  Attached is an updated version of the patch, which is created on top of the patch set [1].  The patch is still WIP (ie, needs more comments and regression tests, at least), but any comments would be gratefully appreciated.

Best regards,
Etsuro Fujita

[1] https://www.postgresql.org/message-id/11eafd10-d3f8-ac8a-b642-b0e65037c76b%40lab.ntt.co.jp


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers




--
Rushabh Lathia

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take
Next
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take