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.94.2) (envelope-from ) id 1v2BEV-0016R2-So for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Sep 2025 16:23:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v2BET-003sO0-UQ for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Sep 2025 16:23:42 +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.94.2) (envelope-from ) id 1v2BET-003sNr-LO for pgsql-hackers@lists.postgresql.org; Fri, 26 Sep 2025 16:23:42 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v2BER-0003fO-37 for pgsql-hackers@postgresql.org; Fri, 26 Sep 2025 16:23:41 +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 58QGNZYL4085065; Fri, 26 Sep 2025 12:23:35 -0400 From: Tom Lane To: David Christensen cc: Andrey Borodin , Peter Eisentraut , pgsql-hackers , "David G. Johnston" , Jelte Fennema-Nio Subject: Re: [PATCH] GROUP BY ALL In-reply-to: References: <4D2047B0-E8D8-472B-B7E8-61206B1E6AFA@yandex-team.ru> <4083063.1758902694@sss.pgh.pa.us> Comments: In-reply-to David Christensen message dated "Fri, 26 Sep 2025 11:13:04 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <4085063.1758903815.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 26 Sep 2025 12:23:35 -0400 Message-ID: <4085064.1758903815@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Christensen writes: > On Fri, Sep 26, 2025 at 11:05 AM Tom Lane wrote: >> contain_agg_clause will blow up on a SubLink, so I doubt this is >> gonna be robust. > Fair enough, see that Assert now; easy enough to make a new > expression_tree_walker that only looks for Aggref and short-circuits > SubLink (which I assume is the right behavior here, but might have to > add some more tests/play around with subqueries in the GROUP BY ALL > part). No, I think the correct behavior would have to be to descend into SubLinks to see if they contain any aggregates belonging to the outer query level. However (looks around) we do already have that code. See contain_aggs_of_level. (contain_agg_clause is essentially a simplified version that is okay to use in the planner because it's already gotten rid of sublinks.) What mainly concerns me at this point is whether we've identified aggregate levels at the point in parsing where you want to run this. I have a bit of a worry that that might interact with grouping. Presumably the SQL committee thought about that, so it's probably soluble, but ... regards, tom lane