public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Pyhalov <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Matheus Alcantara <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Subject: Re: Asynchronous MergeAppend
Date: Tue, 14 Apr 2026 12:48:45 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAFY6G8d3Yvxa_kRQA24BsJhwqfmSCv1ujiv_7b6g5isf-ZTs_Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfdu+3Eud0CBpdFT+osWiT=e=zOQUtBsx8Z5okKrqhgVAJg@mail.gmail.com>
<[email protected]>
<CAPpHfdsO8zYpDW==D6T5N0cJ+AzK7a_OyXJoYU1kFi=xZFTLuQ@mail.gmail.com>
<[email protected]>
<CAPpHfdssDymMVohXw5XwdPoJ9UvSv1iN2zRcmsEhhfXXks01Zg@mail.gmail.com>
<[email protected]>
Alexander Pyhalov писал(а) 2026-04-13 18:09:
> 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.
Haven't found anything suspicious (besides redundant empty line after
enable_async_merge_append GUC description in
src/backend/utils/misc/guc_parameters.dat). Tested it and was a bit
surprised that new async Merge Append version (without async machinery
after nodeMergeAppend initialization) was about 5% faster than the old
one with concurrent queries (-j 16) and 10-15% faster with single-thread
load (when there was a lot of CPU capacity) in my tests (test was
basically the same as in [1]). So, async machinery after Merge Append
node is initialized was not only useless, but even harmful.
Test results:
patch version | concurrency | async_capable off | async_capable on
old | -c 1 -j 1 | 880 tps | 1428 tps (+62%)
old | -c 16 -j 16 | 5190 tps | 4933 tps (-5%)
new | -c 1 -j 1 | 888 tps | 1582 tps (+78%)
new | -c 16 -j 16 | 5020 tps | 5256 tps (+4%)
1.
https://www.postgresql.org/message-id/159b591411bb2c81332018927acbd509%40postgrespro.ru
--
Best regards,
Alexander Pyhalov,
Postgres Professional
view thread (33+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Asynchronous MergeAppend
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox