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 1v0G4S-00CM7v-KQ for pgsql-bugs@arkaria.postgresql.org; Sun, 21 Sep 2025 09:09:24 +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 1v0G4P-00EaBt-N6 for pgsql-bugs@arkaria.postgresql.org; Sun, 21 Sep 2025 09:09:21 +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 1v0G4P-00EaBj-BZ for pgsql-bugs@lists.postgresql.org; Sun, 21 Sep 2025 09:09:21 +0000 Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1v0G4H-001ZLm-1t for pgsql-bugs@lists.postgresql.org; Sun, 21 Sep 2025 09:09:15 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id CCA5343383; Sun, 21 Sep 2025 09:09:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postgresfriends.org; s=gm1; t=1758445746; 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: in-reply-to:in-reply-to:references:references; bh=GZQfodDt085JUd73lQ1vl2ctRtbZECnQ/KBelEzH0CE=; b=QYilqlITZMevA8Kf6NctnNhszreAa/ZABLgBAbC/8BkwP1qQaQ5ZI/AB/tcJsAOzAXF9sy HbUOK1ShGt3uWF/V33P992Xi3TFIkEj0cB1cZgoJSWZhpjzpwlATRv2srYfZCYp0p7mwwN 49o6T7AQcT7QfLttz6+fc9FNERwWzYrUk12BiA1e0SqLumYfu+U8sFFJx7cbNIv04tVSyR KS4no/5bGhF9DJDLWhGY5qUnQ4zscDhUw35sT8it+7uRxafXKsQNYtvssYQ95d4X0N/J0g +pKPH0Otx8gELuXqtuu58jKVug7WowF8KlCfzHmHsUUZQ05uwu0NPDo5u/DU8w== Content-Type: multipart/alternative; boundary="------------j6maemmgEgb28eeXXWwDjBGY" Message-ID: Date: Sun, 21 Sep 2025 11:09:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation To: Christophe Pettus , Tom Lane Cc: jinhui.lai@qq.com, pgsql-bugs@lists.postgresql.org References: <19059-c751eed385314309@postgresql.org> <2510592.1758403162@sss.pgh.pa.us> <84B5D601-C007-4B07-9ECB-CDD06E47B949@thebuild.com> Content-Language: en-US From: Vik Fearing In-Reply-To: <84B5D601-C007-4B07-9ECB-CDD06E47B949@thebuild.com> X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdehgeehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucenucfjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpeggihhkucfhvggrrhhinhhguceovhhikhesphhoshhtghhrvghsfhhrihgvnhgushdrohhrgheqnecuggftrfgrthhtvghrnhepgfejfeduffffleejuedtjeffffetjeeuhfetkeehheektdejkedtgeejgefghfdtnecukfhppedvrgdtgeemtggvtgdtmeduudgukeemkeekjeeimedugeekieemfhgrtghfmeefhegtfhemieehfeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvdgrtdegmegtvggttdemudduugekmeekkeejieemudegkeeimehfrggtfhemfeehtghfmeeiheefkedphhgvlhhopeglkffrggeimedvrgdtgeemtggvtgdtmeduudgukeemkeekjeeimedugeekieemfhgrtghfmeefhegtfhemieehfeekngdpmhgrihhlfhhrohhmpehvihhksehpohhsthhgrhgvshhfrhhivghnughsrdhorhhgpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepgihofhesthhhvggsuhhilhgurdgtohhmpdhrtghpthhtohepthhglhesshhsshdrphhghhdrphgrrdhushdprhgtphhtthhopehjihhnhhhuihdrlhgrihesqhhqrdgtohhmpdhrtghpthhtohepphhgshhqlhdqs ghughhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-GND-Sasl: vik@postgresfriends.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------j6maemmgEgb28eeXXWwDjBGY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 21/09/2025 00:54, Christophe Pettus wrote: >> On Sep 20, 2025, at 14:19, Tom Lane wrote: >> While we've not gotten a huge amount of push-back about the top-level >> re-ordering, there's been some complaints. So I'm not eager to >> propagate the idea further down. > And tangentially, doesn't the SQL standard make it implementation-defined if OR short-circuits or not? > Not that I can see.  The only implementation-defined mention in is: "If the SQL-implementation supports Feature T101, “Enhanced nullability determination”, and if BVE conforms to an implementation-defined (IE011) rule that enables the SQL-implementation to correctly infer that, when BVE is True, then X cannot be null, then BVE is a known-not-null condition for X. " -- Vik Fearing --------------j6maemmgEgb28eeXXWwDjBGY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 21/09/2025 00:54, Christophe Pettus wrote: 
On Sep 20, 2025, at 14:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
While we've not gotten a huge amount of push-back about the top-level
re-ordering, there's been some complaints.  So I'm not eager to
propagate the idea further down.

And tangentially, doesn't the SQL standard make it implementation-defined if OR short-circuits or not?


Not that I can see.  The only implementation-defined mention in <boolean value expression> is:


"If the SQL-implementation supports Feature T101, “Enhanced nullability determination”, and if BVE conforms to an implementation-defined (IE011) rule that enables the SQL-implementation to correctly infer that, when BVE is True, then X cannot be null, then BVE is a known-not-null condition for X. "

-- 

Vik Fearing

--------------j6maemmgEgb28eeXXWwDjBGY--