On 2016/05/31 14:53, Amit Langote wrote:
On 2016/05/30 22:59, Craig Ringer wrote:
On 30 May 2016 at 16:17, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:

That's a good point, but the basic idea is to send the local query
almost-as-is to the remote server if possible.  For example, if the local
query is "INSERT INTO foreign_table(a,b,c) VALUES (1, 2, 3), (4, 5, 6)",
send the remote query "INSERT INTO remote_table(a,b,c) VALUES (1, 2, 3),
(4, 5, 6)" to the remote server where remote_table is the table name for
the foreign table on the remote server.  So, wouldn't the query string
length be a problem in many cases?  Maybe I'm missing something, though.

FDWs don't operate at that level. They don't see the original query string.
They're plan nodes that operate with a row-by-row push/pull model. The
foreign table node in question has no idea you're doing a multivalued
insert and doesn't care if it's INSERT INTO ... SELECT, INSERT INTO ...

IIUC, what Fujita-san seems to be referring to here is safe push-down of a
insert's query or values expression (and hence the whole insert itself)
considered during the *planning* step.

That's really what I have in mind.  Thanks for the explanation!

Although that sounds like a
different optimization from  what's being discussed on this thread.  The
latter certainly seems to have its benefits in case of push-down failure
and might as well be the majority of cases.


Best regards,
Etsuro Fujita

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

Reply via email to