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 1kLsXu-0002A5-VV for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Sep 2020 18:34:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kLsXt-0000Rt-US for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Sep 2020 18:34:13 +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 1kLsXt-0000Rl-LL for pgsql-hackers@lists.postgresql.org; Fri, 25 Sep 2020 18:34:13 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kLsXn-0002k4-Ci for pgsql-hackers@lists.postgresql.org; Fri, 25 Sep 2020 18:34:13 +0000 Received: from [172.20.10.3] (unknown [45.137.112.144]) (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 62FBC21C3953; Fri, 25 Sep 2020 21:34:06 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1601058846; bh=YJLPP6kW///5E41v2ml+MBRON6F8pMRk6AYcUYRmr4U=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=iiL+NLzwzwQd76SxeEArI33HBGHlfwzCMW1WvmqIk+fJ1rrtKNHJx8eO1mkjP2naW stnMq5oByml/7WYEx4GrM0jIGpWBYfzsL4LXCj8+TTtlIEpIgF/jFKEgR/uuVgF1RE e2ujVr5v4mmJjx8ln9C9zCCIrSmrbdgQVLrS8veU= Subject: Re: Asynchronous Append on postgres_fdw nodes. To: Kyotaro Horiguchi , pryzby@telsasoft.com Cc: etsuro.fujita@gmail.com, movead.li@highgo.ca, pgsql-hackers@lists.postgresql.org References: <20200610.120510.2075667454883130505.horikyota.ntt@gmail.com> <20200702.111448.2019475770338322857.horikyota.ntt@gmail.com> <20200820042536.GB2886@telsasoft.com> <20200820.163608.1893015081639298019.horikyota.ntt@gmail.com> From: Andrey Lepikhov Organization: Postgres Professional Message-ID: <158ef5e2-652e-25c1-045b-be71a5df3b2b@postgrespro.ru> Date: Fri, 25 Sep 2020 21:34:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200820.163608.1893015081639298019.horikyota.ntt@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Your AsyncAppend doesn't switch to another source if the data in current leader is available: /* * The request for the next node cannot be sent before the leader * responds. Finish the current leader if possible. */ if (PQisBusy(leader_state->s.conn)) { int rc = WaitLatchOrSocket(NULL, WL_SOCKET_READABLE | WL_TIMEOUT | WL_EXIT_ON_PM_DEATH, PQsocket(leader_state->s.conn), 0, WAIT_EVENT_ASYNC_WAIT); if (!(rc & WL_SOCKET_READABLE)) available = false; } /* fetch the leader's data and enqueue it for the next request */ if (available) { fetch_received_data(leader); add_async_waiter(leader); } I don't understand, why it is needed. If we have fdw connections with different latency, then we will read data from the fast connection first. I think this may be a source of skew and decrease efficiency of asynchronous append. For example, see below synthetic query: CREATE TABLE l (a integer) PARTITION BY LIST (a); CREATE FOREIGN TABLE f1 PARTITION OF l FOR VALUES IN (1) SERVER lb OPTIONS (table_name 'l1'); CREATE FOREIGN TABLE f2 PARTITION OF l FOR VALUES IN (2) SERVER lb OPTIONS (table_name 'l2'); INSERT INTO l (a) SELECT 2 FROM generate_series(1,200) as gs; INSERT INTO l (a) SELECT 1 FROM generate_series(1,1000) as gs; EXPLAIN ANALYZE (SELECT * FROM f1) UNION ALL (SELECT * FROM f2) LIMIT 400; Result: Limit (cost=100.00..122.21 rows=400 width=4) (actual time=0.483..1.183 rows=400 loops=1) -> Append (cost=100.00..424.75 rows=5850 width=4) (actual time=0.482..1.149 rows=400 loops=1) -> Foreign Scan on f1 (cost=100.00..197.75 rows=2925 width=4) (actual time=0.481..1.115 rows=400 loops=1) -> Foreign Scan on f2 (cost=100.00..197.75 rows=2925 width=4) (never executed) As you can see, executor scans one input and doesn't tried to scan another. -- regards, Andrey Lepikhov Postgres Professional