Re: Asynchronous MergeAppend

Hi Alexander,

On Wed, Oct 28, 2026 at 8:37 PM Alexander Pyhalov
<a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
> I've looked through the updated patch.
> It looks good, but I've found some misprints in comments:
>
> 1) postgres_fdw.c - you have a typo here

[snip]

> s/csse/case/

Fixed. I also tweaked the comments a bit further.

> 2) nodeMergeAppend.c:
>
> 199 if (mergestate->ms_nasyncplans > 0)
> 200 {
> 201 mergestate->ms_asyncrequests = (AsyncRequest **)
> 202 palloc0(nplans * sizeof(AsyncRequest *));
> 203
>
> We could use palloc0_array as in surrounding code.

Done.

> 3) One more issue is that we change current semantics of
> ForeignAsyncConfigureWait - out-of-tree FDWs
> now should handle MergeAppendState in addition to AppendState as
> requestor. Should we at least document it?

Agreed. I updated fdwhandler.sgml to incorporate that perspective. I
updated postgres-fdw.sgml and src/backend/executor/README as well.

I also adjusted regression test cases and their comments. While doing
that, I noticed these test cases:

+-- Test async Merge Append rescan when a LIMIT stops the scan before every
+-- async subplan's request has completed, so on the next rescan (for the
+-- next outer row) some subplan's request is still in flight.
+EXPLAIN (VERBOSE, COSTS OFF)
+SELECT g.i, s.b FROM generate_series(1, 3) g(i),
+ LATERAL (SELECT b FROM async_pt WHERE a > g.i ORDER BY b LIMIT 1) s;

+-- Test async Merge Append rescan when a LIMIT stops the scan before an
+-- async subplan's already-delivered result was ever consumed (because it
+-- didn't win the race to the heap top). The next rescan (for the next
+-- outer row) must not mistake that leftover result for a fresh one; the
+-- expected result increases each row, so a stale reused value would show
+-- up as the first row's value repeating instead.
+EXPLAIN (VERBOSE, COSTS OFF)
+SELECT g.i, s.b FROM generate_series(1, 3) g(i),
+ LATERAL (SELECT b FROM async_pt WHERE a > g.i AND b > g.i * 100
ORDER BY b LIMIT 1) s;

These are testing the old implementation? There are two more test
cases for testing the rescan, which seems to me good enough, so I just
removed them (and adjusted the comments for the remaining test cases).
Maybe I'm missing something, though.

Attached is an updated patch.

Thanks for reviewing!

Best regards,
Etsuro Fujita