Re: Asynchronous Append on postgres_fdw nodes.
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-03T09:49:59Z
Lists: pgsql-hackers
On Tue, May 11, 2021 at 6:55 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Tue, May 11, 2021 at 6:27 PM Andrey Lepikhov > <a.lepikhov@postgrespro.ru> wrote: > > On 11/5/21 12:24, Etsuro Fujita wrote: > > > >> -> Append (actual rows=3000 loops=1) > > >> -> Async Foreign Scan on f1 (actual rows=0 loops=1) > > >> -> Async Foreign Scan on f2 (actual rows=0 loops=1) > > >> -> Foreign Scan on f3 (actual rows=3000 loops=1) > > >> > > >> Here we give preference to the synchronous scan. Why? > > > > > > This would be expected behavior, and the reason is avoid performance > > > degradation; you might think it would be better to execute the async > > > Foreign Scan nodes more aggressively, but it would require > > > waiting/polling for file descriptor events many times, which is > > > expensive and might cause performance degradation. I think there is > > > room for improvement, though. > > Yes, I agree with you. Maybe you can add note in documentation on > > async_capable, for example: > > "... Synchronous and asynchronous scanning strategies can be mixed by > > optimizer in one scan plan of a partitioned table or an 'UNION ALL' > > command. For performance reasons, synchronous scans executes before the > > first of async scan. ..." > > +1 But I think this is an independent issue, so I think it would be > better to address the issue separately. I think that since postgres-fdw.sgml would be for users rather than developers, unlike fdwhandler.sgml, it would be better to explain this more in a not-too-technical way. So how about something like this? Asynchronous execution is applied even when an Append node contains subplan(s) executed synchronously as well as subplan(s) executed asynchronously. In that case, if the asynchronous subplans are ones executed using postgres_fdw, tuples from the asynchronous subplans are not returned until after at least one synchronous subplan returns all tuples, as that subplan is executed while the asynchronous subplans are waiting for the results of queries sent to foreign servers. This behavior might change in a future release. 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