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-03-31T05:12:07Z
Lists: pgsql-hackers
On Wed, Mar 31, 2021 at 10:11 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > + <term><literal>async_capable</literal></term> > + <listitem> > + <para> > + This option controls whether <filename>postgres_fdw</filename> allows > + foreign tables to be scanned concurrently for asynchronous execution. > + It can be specified for a foreign table or a foreign server. > > Isn't it strange that an option named "async_capable" *allows* async? I think "async_capable" is a good name for that option. See the option "updatable" below in the postgres_fdw documentation. > + * We'll prefer to consider this join async-capable if any table from > + * either side of the join is considered async-capable. > + */ > + fpinfo->async_capable = fpinfo_o->async_capable || > + fpinfo_i->async_capable; > > We need to explain this behavior in the documentation. > > Regarding to the wording "async capable", if it literally represents > the capability to run asynchronously, when any one element of a > combined path doesn't have the capability, the whole path cannot be > async-capable. If it represents allowance for an element to run > asynchronously, then the whole path is inhibited to run asynchronously > unless all elements are allowed to do so. If it represents > enforcement or suggestion to run asynchronously, enforcing asynchrony > to an element would lead to running the whole path asynchronously > since all elements of postgres_fdw are capable to run asynchronously > as the nature. > > It looks somewhat inconsistent to be inhibitive for the default value > of "async_capable", but agressive in merging? If the foreign table has async_capable=true, it actually means that there are resources (CPU, IO, network, etc.) to scan the foreign table concurrently. And if any table from either side of the join has such resources, then they could also be used for the join. So I don't think this behavior is aggressive. I think it would be better to add more comments, though. Anyway, these are all about naming and docs/comments, so I'll return to this after committing the patch. Thanks for the review! 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