Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eF2p7-0001ss-HS for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Nov 2017 18:54:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eF2p6-0008VQ-Qp for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Nov 2017 18:54:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eF2p6-0008VG-LU for pgsql-hackers@lists.postgresql.org; Wed, 15 Nov 2017 18:54:08 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eF2p3-0004Lq-O6 for pgsql-hackers@postgresql.org; Wed, 15 Nov 2017 18:54:08 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 746D020E98; Wed, 15 Nov 2017 13:54:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 15 Nov 2017 13:54:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=B4Jcn5FGWsF5+VH7x62PuLk8HI1yK SNOIAgEsdNaDME=; b=Rm1F2pWsCKX4+vUH5ANCbbjEVu5gzzmmpkz4w/CXKYTBW VuCfPiQ9NdSM1DTV172yA9hWDtQNtRAmMWNAfaJQUQatr4HR0+wh7om9ggyYOTr6 IfM18KOukbPwn0wxYq4VO7jzVwBxzav7liYB0BkSbA/7knpBT6eUsHa7X0UR03lr pvrCvQ9LddSltA7+ROdGjq5Z2fBePk1HLzBwBdqxcIEEv9o0hR1jd0do5vB9kcVN nAkSXS90djyEXhlTH+qUm63Sz77/AnRz0yRnYpVzPAEWPmEbpIpP4bw1TD7TINCd okgM/R7L4nEUhVfBuS+kSCgAOknWVmjzsalyNwHgw== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id 3BB757FAE3; Wed, 15 Nov 2017 13:54:04 -0500 (EST) Date: Wed, 15 Nov 2017 10:54:03 -0800 From: Andres Freund To: Robert Haas Cc: Rafia Sabih , Amit Kapila , PostgreSQL Developers Subject: Re: [HACKERS] [POC] Faster processing at Gather node Message-ID: <20171115185403.xf476nhzpkgoddor@alap3.anarazel.de> References: <20171107193200.5jkjvuhqclcg4bj2@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2017-11-15 13:48:18 -0500, Robert Haas wrote: > I think that we need a little bit deeper analysis here to draw any > firm conclusions. Indeed. > I suspect that one factor is that many of the queries actually send > very few rows through the Gather. Yep. I kinda wonder if the same result would present if the benchmarks were run with parallel_leader_participation. The theory being what were seing is just that the leader doesn't accept any tuples, and the large queue size just helps because workers can run for longer. Greetings, Andres Freund