Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wCIuY-001qtp-14 for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Apr 2026 15:09:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wCIuW-007XbC-2F for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Apr 2026 15:09:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wCIuV-007Xb4-3A for pgsql-hackers@lists.postgresql.org; Mon, 13 Apr 2026 15:09:13 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wCIuT-00000000ohw-2XfR for pgsql-hackers@postgresql.org; Mon, 13 Apr 2026 15:09:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1776092946; bh=eVX3ph5rigUnOEqbhkk5zt2evFuldTWyoN+FYewS+K4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:Message-ID:From; b=5M3hLCbi2MIOyDLyoALHtqZqxhvikFNoSSiQU5cyxjUSnDP0cBpuhvFKy3STANYl3 2HAmass78N05V0swWggUP9Rjlcmzh3Df7gAcJm4LFNteOPhyxeoVlPWEsXg03M4X9q 1FrTA3kDYg8VHP3orY89Q9YtPpq150b2aZ4PZ7L/+IZauo+OGCIklTBSgySGEl0kFK BKJRXeCouLVMZTW8MeuKqn5f0P9QbvaLUx4pQs8KL72Q5K6bQSFN5W6UZYDz1AjpYd 4XvfXGcVw0JJCP9OBa5T0OHPDEF9RvewFdvUUyR2fWYH4hPBAY0X5098Bhy28CRvFu B7L8vp2Tra9lQ== Received: from mail.l.postgrespro.ru (webmail-master-mstn.l.postgrespro.ru [192.168.2.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.pyhalov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 3510E60172; Mon, 13 Apr 2026 18:09:06 +0300 (MSK) MIME-Version: 1.0 Date: Mon, 13 Apr 2026 18:09:06 +0300 From: Alexander Pyhalov To: Alexander Korotkov Cc: Matheus Alcantara , Pgsql Hackers Subject: Re: Asynchronous MergeAppend In-Reply-To: References: <59be194c5a409fb9fc9f2031581b8a44@postgrespro.ru> <2fb1d9923b6995492e7b163e6cb95402@postgrespro.ru> <782a968c8e01ec6db3b2da2120adf73b@postgrespro.ru> <554a73f7ffea8b22b3f81a4804b5fc34@postgrespro.ru> <42a9a941-e768-4fd8-8067-12958c5a1d70@gmail.com> Message-ID: <10c97af0ce34ebdb81708b1c49ed6038@postgrespro.ru> X-Sender: a.pyhalov@postgrespro.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 3.0.0.9059, bases: 2026/04/13 11:56:00 #28395103 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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