Horton

Re: Asynchronous Append on postgres_fdw nodes.

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: a.lepikhov@postgrespro.ru
Cc: etsuro.fujita@gmail.com, movead.li@highgo.ca, pgsql-hackers@lists.postgresql.org
Date: 2020-07-02T02:14:48Z
Lists: pgsql-hackers

Attachments

Hello.

As the result of a discussion with Fujita-san off-list, I'm going to
hold off development until he decides whether mine or Thomas' is
better.

However, I fixed two misbehaviors and rebased.

A. It runs ordered Append asynchronously, but that leads to a bogus
  result. I taught create_append_plan not to make subnodes async when
  pathkey is not NIL.

B. It calculated the total cost of Append by summing up total costs of
  all subnodes including async subnodes.  It is too pessimistic so I
  changed that to the following.

    Max(total cost of sync subnodes, maximum cost of async subnodes);

  However this is a bit too optimistic in that it ignores interference
  between async subnodes, it is more realistic in the cases where the
  subnode ForeignScans are connecting to different servers.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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.