| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | 'Craig Ringer' <craig(dot)ringer(at)enterprisedb(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(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-27 06:05:55 |
| Message-ID: | TYAPR01MB2990D7DA7D44F38E1BBD7FD3FEF80@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
> But in the libpq pipelining patch I demonstrated a 300 times (3000%) performance improvement on a test workload...
Wow, impressive number. I've just seen it in the beginning of the libpq pipelining thread (oh, already four years ago..!) Could you share the workload and the network latency (ping time)? I'm sorry I'm just overlooking it.
Thank you for your (always) concise explanation. I'd like to check other DBMSs and your rich references for the FDW interface. (My first intuition is that many major DBMSs might not have client C APIs that can be used to implement an async pipelining FDW interface. Also, I'm afraid it requires major surgery or reform of executor. I don't want it to delay the release of reasonably good (10x) improvement with the synchronous interface.)
(It'd be kind of you to send emails in text format. I've changed the format of this reply from HTML to text.)
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2020-11-27 06:06:39 | Re: [Patch] Optimize dropping of relation buffers using dlist |
| Previous Message | Masahiko Sawada | 2020-11-27 05:04:51 | Re: Add Information during standby recovery conflicts |