MIME-Version: 1.0
Date: Tue, 14 Apr 2026 12:48:45 +0300
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>
Subject: Re: Asynchronous MergeAppend
In-Reply-To: <10c97af0ce34ebdb81708b1c49ed6038@postgrespro.ru>
References: <59be194c5a409fb9fc9f2031581b8a44@postgrespro.ru>
 <2fb1d9923b6995492e7b163e6cb95402@postgrespro.ru>
 <DE662JHGRO2O.3KJBBG2R3IT17@gmail.com>
 <efbfbcf00b6b790e8f80c13a83417a23@postgrespro.ru>
 <CAFY6G8d3Yvxa_kRQA24BsJhwqfmSCv1ujiv_7b6g5isf-ZTs_Q@mail.gmail.com>
 <b546d8bd5e2218f4f917fda4c93ead21@postgrespro.ru>
 <DED05POJZS2W.2EZ60AOBMDDAE@gmail.com>
 <bcdefce7e3db9566d0619ad2eed2a299@postgrespro.ru>
 <DF0RCOYB19RC.35BW2FHPO4N4S@gmail.com>
 <a16423ca928cde3650bbc219982a5ffc@postgrespro.ru>
 <DF28LV8UTUOO.71JUZDH1N8F9@gmail.com>
 <d5c0bfca6ee15d62df1ba72e540b4ddf@postgrespro.ru>
 <DFAQTF8P9AU0.2ZELZFXOCD0XL@gmail.com>
 <c264abe661f72d6627f987fc9aa4e456@postgrespro.ru>
 <DFBN6K9K9IUG.23WZ7OBL8DRAQ@gmail.com>
 <c0d55d3f68bfd5650fe3143d3a31c84c@postgrespro.ru>
 <782a968c8e01ec6db3b2da2120adf73b@postgrespro.ru>
 <554a73f7ffea8b22b3f81a4804b5fc34@postgrespro.ru>
 <e13717179328abed3e189f4ca1e63087@postgrespro.ru>
 <CAPpHfdu+3Eud0CBpdFT+osWiT=e=zOQUtBsx8Z5okKrqhgVAJg@mail.gmail.com>
 <42a9a941-e768-4fd8-8067-12958c5a1d70@gmail.com>
 <CAPpHfdsO8zYpDW==D6T5N0cJ+AzK7a_OyXJoYU1kFi=xZFTLuQ@mail.gmail.com>
 <DHMH23M7UOFS.12W6PUDI1I3NH@gmail.com>
 <CAPpHfdssDymMVohXw5XwdPoJ9UvSv1iN2zRcmsEhhfXXks01Zg@mail.gmail.com>
 <10c97af0ce34ebdb81708b1c49ed6038@postgrespro.ru>
Message-ID: <fa7ae004ec282fde84c29f36e0c85979@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/fa7ae004ec282fde84c29f36e0c85979%40postgrespro.ru>
Precedence: bulk

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