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.ets...@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-b64 > 2-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
