Re: POC: postgres_fdw insert batching
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>,
'Craig Ringer' <craig.ringer@enterprisedb.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
"Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>
Date: 2020-11-26T19:34:04Z
Lists: pgsql-hackers
On 11/26/20 2:48 AM, tsunakawa.takay@fujitsu.com wrote: > From: Tomas Vondra <tomas.vondra@enterprisedb.com> >> Well, good that we all agree this is a useful feature to have (in >> general). The question is whether postgres_fdw should be doing >> batching on it's onw (per this thread) or rely on some other >> feature (libpq pipelining). I haven't followed the other thread, >> so I don't have an opinion on that. > > Well, as someone said in this thread, I think bulk insert is much > more common than updates/deletes. Thus, major DBMSs have INSERT > VALUES(record1), (record2)... and INSERT SELECT. Oracle has direct > path INSERT in addition. As for the comparison of INSERT with > multiple records and libpq batching (= multiple INSERTs), I think > the former is more efficient because the amount of data transfer is > less and the parsing-planning of INSERT for each record is > eliminated. > > I never deny the usefulness of libpq batch/pipelining, but I'm not > sure if app developers would really use it. If they want to reduce > the client-server round-trips, won't they use traditional stored > procedures? Yes, the stored procedure language is very > DBMS-specific. Then, I'd like to know what kind of well-known > applications are using standard batching API like JDBC's batch > updates. (Sorry, I think that should be discussed in libpq > batch/pipelining thread and this thread should not be polluted.) > Not sure how is this related to app developers? I think the idea was that the libpq features might be useful between the two PostgreSQL instances. I.e. the postgres_fdw would use the libpq batching to send chunks of data to the other side. > >> Note however we're doing two things here, actually - we're >> implementing custom batching for postgres_fdw, but we're also >> extending the FDW API to allow other implementations do the same >> thing. And most of them won't be able to rely on the connection >> library providing that, I believe. > > I'm afraid so, too. Then, postgres_fdw would be an example that > other FDW developers would look at when they use INSERT with > multiple records. > Well, my point was that we could keep the API, but maybe it should be implemented using the proposed libpq batching. They could still use the postgres_fdw example how to use the API, but the internals would need to be different, of course. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Fix tuple routing to initialize batching only for inserts
- 927f453a9410 14.0 landed
-
Fix pointer type in ExecForeignBatchInsert SGML docs
- c15283ff429b 14.0 landed
-
Fix initialization of FDW batching in ExecInitModifyTable
- 920f853dc948 14.0 landed
-
Implement support for bulk inserts in postgres_fdw
- b663a4136331 14.0 landed