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 1oJ25n-0002tb-1O for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 00:18:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oJ25l-0002dE-AK for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 00:18:29 +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 1oJ25l-0002d5-1I for pgsql-hackers@lists.postgresql.org; Wed, 03 Aug 2022 00:18:29 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJ25h-0006NU-4v for pgsql-hackers@postgresql.org; Wed, 03 Aug 2022 00:18:28 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2730IKNl2800169; Tue, 2 Aug 2022 20:18:20 -0400 From: Tom Lane To: David Rowley cc: PostgreSQL-development , Robert Haas , Stephen Frost , Andres Freund , Tomas Vondra Subject: Re: Parallel Aggregates for string_agg and array_agg In-reply-to: References: <24abe018-b3c6-2117-b5b9-39e660db00bd@2ndquadrant.com> <1b6ee15c-c218-761e-0120-c1ed438e2db2@2ndquadrant.com> <657be73a-a21d-0ae1-5c62-870afbdfddd4@2ndquadrant.com> <20180326022647.GL24540@tamriel.snowman.net> <20180326132009.GN24540@tamriel.snowman.net> <6538.1522096067@sss.pgh.pa.us> <15683.1525208375@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Wed, 03 Aug 2022 11:45:31 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2800167.1659485900.1@sss.pgh.pa.us> Date: Tue, 02 Aug 2022 20:18:20 -0400 Message-ID: <2800168.1659485900@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > Waking up this old thread again. If you don't have a copy, the entire > thread is in [1]. > The remaining item that seemed to cause this patch to be rejected was > raised in [2]. Hmm. My estimate of the percentages of users who will be pleased or not hasn't really changed since [2]. Also, realizing that you can't apply these aggregates to extremely large input sets, I wonder just how much it buys to be able to parallelize them. So I still put this patch in the category of "just because we can doesn't mean we should". Now as against that, if the underlying relation scan is parallelized then you already have unpredictable input ordering and thus unpredictable aggregate results. So anyone who cares about that has already had to either disable parallelism or insert an ORDER BY somewhere, and either of those fixes will still work if the aggregates support parallelism. Hence, I'm not going to fight hard if you really want to do it. But I remain unconvinced that the cost/benefit tradeoff is attractive. regards, tom lane