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 →
-
Handle interrupts while waiting on Append's async subplans
- af717317a04f 18.0 cited