Re: Asynchronous Append on postgres_fdw nodes.
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
Andrey Lepikhov <a.lepikhov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-06T06:25:25Z
Lists: pgsql-hackers
Attachments
- note-about-async.patch (application/octet-stream) patch
On Thu, Mar 4, 2021 at 1:00 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > Another thing I'm concerned about in the postgres_fdw part is the case > where all/many postgres_fdw ForeignScans of an Append use the same > connection, because in that case those ForeignScans are executed one > by one, not in parallel, and hence the overhead of async execution > (i.e., doing ExecAppendAsyncEventWait()) would merely cause a > performance degradation. Here is such an example: > > postgres=# create server loopback foreign data wrapper postgres_fdw > options (dbname 'postgres'); > postgres=# create user mapping for current_user server loopback; > postgres=# create table pt (a int, b int, c text) partition by range (a); > postgres=# create table loct1 (a int, b int, c text); > postgres=# create table loct2 (a int, b int, c text); > postgres=# create table loct3 (a int, b int, c text); > postgres=# create foreign table p1 partition of pt for values from > (10) to (20) server loopback options (table_name 'loct1'); > postgres=# create foreign table p2 partition of pt for values from > (20) to (30) server loopback options (table_name 'loct2'); > postgres=# create foreign table p3 partition of pt for values from > (30) to (40) server loopback options (table_name 'loct3'); > postgres=# insert into p1 select 10 + i % 10, i, to_char(i, 'FM00000') > from generate_series(0, 99999) i; > postgres=# insert into p2 select 20 + i % 10, i, to_char(i, 'FM00000') > from generate_series(0, 99999) i; > postgres=# insert into p3 select 30 + i % 10, i, to_char(i, 'FM00000') > from generate_series(0, 99999) i; > postgres=# analyze pt; > > postgres=# set enable_async_append to off; > postgres=# select count(*) from pt; > count > -------- > 300000 > (1 row) > > Time: 366.905 ms > > postgres=# set enable_async_append to on; > postgres=# select count(*) from pt; > count > -------- > 300000 > (1 row) > > Time: 385.431 ms I think the user should be careful about this. How about adding a note about it to the “Asynchronous Execution Options” section in postgres-fdw.sgml, like the attached? Best regards, Etsuro Fujita
Commits
-
Improve comments for trivial_subqueryscan().
- 4a8a5dd7f59c 15.0 landed
-
Disable asynchronous execution if using gating Result nodes.
- ebb790241523 14.3 landed
- 5c854e7a2c8a 15.0 landed
-
Allow asynchronous execution in more cases.
- c2bb02bc2e85 15.0 landed
-
Doc: Further update documentation for asynchronous execution.
- eab81953682d 14.0 landed
-
Fix rescanning of async-aware Append nodes.
- f3baaf28a6da 14.0 landed
-
Doc: Update documentation for asynchronous execution.
- 15fcd33e0694 14.0 landed
-
Fix EXPLAIN ANALYZE for async-capable nodes.
- a363bc6da96b 14.0 landed
-
Minor code cleanup in asynchronous execution support.
- bb684c82f733 14.0 landed
-
Adjust input value to WaitEventSetWait() in ExecAppendAsyncEventWait().
- a8af856d3257 14.0 landed
-
Add support for asynchronous execution.
- 27e1f14563cf 14.0 landed