Re: Asynchronous MergeAppend

Alexander Pyhalov <a.pyhalov@postgrespro.ru>

From: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-13T15:09:06Z
Lists: pgsql-hackers
Hi.

Looked at it. Overall I agree that when we wait for data from one slot 
after node initialization, we can't get data from other slots - they are 
already either exhausted, or have already received data which is not 
needed for now. So it seems that async machinery on later stages is 
useless.

Was a bit surprised that asyncresults field is not used in async merge 
append anymore, as we save result directly in ms_slots. However, as we 
do it only on initial stage, this seems to be OK.

classify_matching_subplans() comment still refers to ms_valid_subplans.

Will look at it once again tomorrow.
-- 
Best regards,
Alexander Pyhalov,
Postgres Professional



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Handle interrupts while waiting on Append's async subplans