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 1v06UO-00AhMF-Bn for pgsql-bugs@arkaria.postgresql.org; Sat, 20 Sep 2025 22:55:32 +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 1v06UL-00E5Ql-2O for pgsql-bugs@arkaria.postgresql.org; Sat, 20 Sep 2025 22:55:29 +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 1v06UK-00E5QB-MI for pgsql-bugs@lists.postgresql.org; Sat, 20 Sep 2025 22:55:28 +0000 Received: from smtp126.ord1d.emailsrvr.com ([184.106.54.126]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1v06UI-001VUa-11 for pgsql-bugs@lists.postgresql.org; Sat, 20 Sep 2025 22:55:27 +0000 X-Auth-ID: xof@thebuild.com Received: by smtp8.relay.ord1d.emailsrvr.com (Authenticated sender: xof-AT-thebuild.com) with ESMTPSA id 71FE6C0245; Sat, 20 Sep 2025 18:55:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.4\)) Subject: Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation From: Christophe Pettus In-Reply-To: <2510592.1758403162@sss.pgh.pa.us> Date: Sat, 20 Sep 2025 15:54:54 -0700 Cc: jinhui.lai@qq.com, pgsql-bugs@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <84B5D601-C007-4B07-9ECB-CDD06E47B949@thebuild.com> References: <19059-c751eed385314309@postgresql.org> <2510592.1758403162@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3776.700.51.11.4) X-Classification-ID: 88eb90d6-ba63-4916-bed6-128f23d5ed4d-1-1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > 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?=