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. >> <http://www.postgresql.org/mailpref/pgsql-hackers> > > 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 ... > VALUES, or COPY.
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. 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. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
