Re: Optimization for updating foreign tables in Postgres FDW - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Optimization for updating foreign tables in Postgres FDW
Date
Msg-id 5656CA46.4030507@lab.ntt.co.jp
Whole thread Raw
In response to Re: Optimization for updating foreign tables in Postgres FDW  (Thom Brown <thom@linux.com>)
Responses Re: Optimization for updating foreign tables in Postgres FDW  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Hi Thom,

Thank you for paying attention to this!

On 2015/11/25 20:36, Thom Brown wrote:
> On 13 May 2015 at 04:10, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
>> On 2015/05/13 0:55, Stephen Frost wrote:
>>> While the EXPLAIN output changed, the structure hasn't really changed
>>> from what was discussed previously and there's not been any real
>>> involvment from the core code in what's happening here.
>>>
>>> Clearly, the documentation around how to use the FDW API hasn't changed
>>> at all and there's been no additions to it for handling bulk work.
>>> Everything here continues to be done inside of postgres_fdw, which
>>> essentially ignores the prescribed "Update/Delete one tuple" interface
>>> for ExecForeignUpdate/ExecForeignDelete.
>>>
>>> I've spent the better part of the past two days trying to reason my way
>>> around that while reviewing this patch and I haven't come out the other
>>> side any happier with this approach than I was back in
>>> 20140911153049.GC16422@tamriel.snowman.net.
>>>
>>> There are other things that don't look right to me, such as what's going
>>> on at the bottom of push_update_down(), but I don't think there's much
>>> point going into it until we figure out what the core FDW API here
>>> should look like.  It might not be all that far from what we have now,
>>> but I don't think we can just ignore the existing, documented, API.

>> OK, I'll try to introduce the core FDW API for this (and make changes to the
>> core code) to address your previous comments.

> I'm a bit behind in reading up on this, so maybe it's been covered
> since, but is there a discussion of this API on another thread, or a
> newer patch available?

Actually, I'm now working on this.  My basic idea is to add new FDW APIs 
for handling the bulk work, in order not to make messy the prescribed 
"Update/Delete one tuple" interface; 1) add to nodeModifyTable.c or 
nodeForeignscan.c the new FDW APIs BeginPushedDownForeignModify, 
ExecPushedDownForeignModify and EndPushedDownForeignModify for that, and 
2) call these FDW APIs, instead of BeginForeignModify, 
ExecForeignUpdate/ExecForeignDelete and EndForeignModify, when doing 
update pushdown.  I'd like to propose that in more detail as soon as 
possible, probably with an updated patch.

Best regards,
Etsuro Fujita




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: parallel joins, and better parallel explain
Next
From: Magnus Hagander
Date:
Subject: Re: pg_stat_replication log positions vs base backups