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.96) (envelope-from ) id 1vIq6U-00GPVa-2A for pgsql-bugs@arkaria.postgresql.org; Tue, 11 Nov 2025 15:16:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vIq6S-006YRL-1j for pgsql-bugs@arkaria.postgresql.org; Tue, 11 Nov 2025 15:16:16 +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.96) (envelope-from ) id 1vIq6S-006YQe-0U for pgsql-bugs@lists.postgresql.org; Tue, 11 Nov 2025 15:16:16 +0000 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1vIq6M-006ZEI-2t for pgsql-bugs@lists.postgresql.org; Tue, 11 Nov 2025 15:16:15 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id D8AE344330; Tue, 11 Nov 2025 15:16:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postgresfriends.org; s=gm1; t=1762874168; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=luzZp5tDLlRpOMnTQGojnW98u+aHqm23jXFpfNkeuoU=; b=Eb3JyZJNIX1FZ3IGbqYs70FZWNon4AoEmpZVvqgOAs37NbcboxvL8P2L8jXxmL9QzATHfv LrGmUIJCL2SIGsKjdS+ejlL1JfT6d3gLw4Rmxoz2vjh5cNNxlDo8WHC4rT3+RF37t4f4k7 MT9Gf13XMh+WgIrfQgJj4LW4BPX1hnA8kv928SrG/9DNDVcQKM7k3iXmglSqNQ2LX47tmp HycndxP0n5hFJTjo2hSxYncJ5hhDoVFRE9vC9KkdhUInr7ApRkCapeoMt6kPGEPIId+c5i q3/er2K4yFJ6eruflrpIo81LREVGdjgUBmtuKBjLa2Ztr5b0U1Zy4WPAT8y6YA== Message-ID: <36c1f631-f65f-4bb8-90af-9fafdb683547@postgresfriends.org> Date: Tue, 11 Nov 2025 16:16:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #19106: Potential regression with CTE materialization planning in Postgres 18 To: Tom Lane , Kamil Monicz Cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut References: <19106-9dd3668a0734cd72@postgresql.org> <1650412.1762703636@sss.pgh.pa.us> <1886977.1762794560@sss.pgh.pa.us> <1980046.1762808758@sss.pgh.pa.us> Content-Language: en-US From: Vik Fearing In-Reply-To: <1980046.1762808758@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvtdduheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepgghikhcuhfgvrghrihhnghcuoehvihhksehpohhsthhgrhgvshhfrhhivghnughsrdhorhhgqeenucggtffrrghtthgvrhhnpedutdevfeelgedvuddtjefhhfelhefhveehieelhfegtedtuefhtdffgedvgfetffenucfkphepkeehrddvvdelrdeiiedrkeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkeehrddvvdelrdeiiedrkeegpdhhvghloheplgdutddrtddruddrvddvngdpmhgrihhlfhhrohhmpehvihhksehpohhsthhgrhgvshhfrhhivghnughsrdhorhhgpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepthhglhesshhsshdrphhghhdrphgrrdhushdprhgtphhtthhopehkrghmihhlsehmohhnihgtiidruggvvhdprhgtphhtthhopehpghhsqhhlqdgsuhhgsheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhgpdhrtghpthhtohepphgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhg X-GND-Sasl: vik@postgresfriends.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 10/11/2025 22:05, Tom Lane wrote: > [ cc'ing Peter and Vik for possible input on SQL-standard question ] Thanks! > WITH a AS ( > SELECT id FROM (VALUES (1), (2)) AS v(id) > ), > b AS ( > SELECT max((SELECT sum(id) FROM a)) AS agg > ) > SELECT agg FROM b; snip > I looked at the SQL standard for possible guidance and found none: > they disallow subqueries altogether within aggregate arguments, > so they need not consider such cases. I am curious though whether > Peter or Vik know if the committee ever considered relaxing that > restriction, and if so whether they stopped to think about this > particular point. I am not seeing that restriction in the standard.  For this test case, we have MAX which has the lineage: MAX Its argument, (SELECT SUM(id) FROM a), has this lineage: Since there are no outer column references, the subquery should be independent. And if we inline it: WITH     b (agg) AS (         SELECT MAX((             SELECT SUM(id)             FROM (VALUES (1), (2)) AS v (id)         ))         -- FROM nothing     ) TABLE b then the query works as expected. MATERIALIZEDing either or both CTEs has no effect, which I find strange. -- Vik Fearing