Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lexH5-0002tF-CZ for pgsql-hackers@arkaria.postgresql.org; Fri, 07 May 2021 10:00:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lexH4-0002vO-8c for pgsql-hackers@arkaria.postgresql.org; Fri, 07 May 2021 09:59:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lexH3-0002u5-T8 for pgsql-hackers@lists.postgresql.org; Fri, 07 May 2021 09:59:58 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lexH2-0004AH-8C for pgsql-hackers@lists.postgresql.org; Fri, 07 May 2021 09:59:57 +0000 Received: from ip-192-168-0-192.is74.loc (pool-77-222-104-44.is74.ru [77.222.104.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 4A4DB21C819D; Fri, 7 May 2021 12:59:53 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1620381593; bh=uLLY2Oswhd9ElwqIZuwwRNkdxCLvXGVvkUc+GRcyv/M=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eqqWvhqqmMdi1axqMWYDVDzk9PFYpZEjhSkg6p1KqZBJ6sZGuxTNRxnv7t2jcvzyu bvjuXqgpjnK3qmrRZLnVQzQWvLtR9iD3Smb5YGc+h4CEUaJs0Xr5UDsdFhNswj7mIn 0dd7nzWUBB1NRO7n0gonenn5PB/0z+ld3rj/X6Zk= Subject: Re: Asynchronous Append on postgres_fdw nodes. To: Stephen Frost , Etsuro Fujita Cc: Kyotaro Horiguchi , Justin Pryzby , PostgreSQL Hackers References: <20210218.151557.1106337659785292399.horikyota.ntt@gmail.com> <20210506171224.GV20766@tamriel.snowman.net> From: Andrey Lepikhov Organization: Postgres Professional Message-ID: Date: Fri, 7 May 2021 14:59:52 +0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210506171224.GV20766@tamriel.snowman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/5/21 22:12, Stephen Frost wrote: > * Etsuro Fujita (etsuro.fujita@gmail.com) wrote: >> I think the user should be careful about this. How about adding a >> note about it to the “Asynchronous Execution Options” section in >> postgres-fdw.sgml, like the attached? +1 > ... then again, it'd really be better if we could figure out a way to > just do the right thing here. I haven't looked at this in depth but I > would think that the overhead of async would be well worth it just about > any time there's more than one foreign server involved. Is it not > reasonable to have a heuristic where we disable async in the cases where > there's only one foreign server, but have it enabled all the other time? > While continuing to allow users to manage it explicitly if they want. Bechmarking of SELECT from foreign partitions hosted on the same server, i see results: With async append: 1 partition - 178 ms; 4 - 263; 8 - 450; 16 - 860; 32 - 1740. Without: 1 - 178 ms; 4 - 583; 8 - 1140; 16 - 2302; 32 - 4620. So, these results show that we have a reason to use async append in the case where there's only one foreign server. -- regards, Andrey Lepikhov Postgres Professional