From: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | tsunakawa(dot)takay(at)fujitsu(dot)com, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: POC: postgres_fdw insert batching |
Date: | 2020-11-28 07:00:31 |
Message-ID: | CAGRY4nxe7ih_y1LrLw1Jjfbowuoii8BWmvTNSaMfyE-COp4Nsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 28 Nov 2020, 10:10 Tomas Vondra, <tomas(dot)vondra(at)enterprisedb(dot)com>
wrote:
>
>
> On 11/27/20 7:05 AM, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:
>
> However, the FDW interface as it's implemented today is not designed to
> allow that, I believe (we pretty much just invoke the FWD callbacks as
> if it was a local AM). It assumes the calls are synchronous, and
> redesigning it to work in async way is a much larger/complex patch than
> what's being discussed here.
>
> I do think the FDW extension proposed here (adding the bulk-insert
> callback) is useful in general, for two reasons: (a) even if most client
> libraries support some sort of pipelining, some don't, and (b) I'd bet
> it's still more efficient to send one large insert than pipelining many
> individual inserts.
>
> That being said, I'm against expanding the scope of this patch to also
> require redesign of the whole FDW infrastructure - that would likely
> mean no such improvement landing in PG14. If the libpq pipelining patch
> seems likely to get committed, we can try using it for the bulk insert
> callback (instead of the current multi-value stuff).
>
I totally agree on all points. It was not my intent to expand the scope of
this significantly and I really don't want to hold it back.
I raised the interface consideration in case it was something easy to
accommodate. It's not, so that's done, topic over.
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2020-11-28 10:31:28 | Re: Improving spin-lock implementation on ARM. |
Previous Message | Tom Lane | 2020-11-28 02:35:57 | Re: Improving spin-lock implementation on ARM. |