Re: Asynchronous Append on postgres_fdw nodes.

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

From: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: etsuro.fujita@gmail.com, movead.li@highgo.ca, pgsql-hackers@lists.postgresql.org
Date: 2020-06-11T07:03:45Z
Lists: pgsql-hackers
On 6/10/20 8:05 AM, Kyotaro Horiguchi wrote:
> Hello, Andrey.
> 
> At Tue, 9 Jun 2020 14:20:42 +0500, Andrey Lepikhov <a.lepikhov@postgrespro.ru> wrote in
>> On 6/4/20 11:00 AM, Kyotaro Horiguchi wrote:
>> 2. Total cost of an Append node is a sum of the subplans. Maybe in the
>> case of asynchronous append we need to use some reduce factor?
> 
> Yes.  For the reason mentioned above, foreign subpaths don't affect
> the startup cost of Append as far as any sync subpaths exist.  If no
> sync subpaths exist, the Append's startup cost is the minimum startup
> cost among the async subpaths.
I mean that you can possibly change computation of total cost of the 
Async append node. It may affect the planner choice between ForeignScan 
(followed by the execution of the JOIN locally) and partitionwise join 
strategies.

Have you also considered the possibility of dynamic choice between 
synchronous and async append (during optimization)? This may be useful 
for a query with the LIMIT clause.

-- 
Andrey Lepikhov
Postgres Professional



Commits

  1. Improve comments for trivial_subqueryscan().

  2. Disable asynchronous execution if using gating Result nodes.

  3. Allow asynchronous execution in more cases.

  4. Doc: Further update documentation for asynchronous execution.

  5. Fix rescanning of async-aware Append nodes.

  6. Doc: Update documentation for asynchronous execution.

  7. Fix EXPLAIN ANALYZE for async-capable nodes.

  8. Minor code cleanup in asynchronous execution support.

  9. Adjust input value to WaitEventSetWait() in ExecAppendAsyncEventWait().

  10. Add support for asynchronous execution.