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 1v06rK-00AlrD-HD for pgsql-bugs@arkaria.postgresql.org; Sat, 20 Sep 2025 23:19:14 +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 1v06rJ-00E7jl-1r for pgsql-bugs@arkaria.postgresql.org; Sat, 20 Sep 2025 23:19:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v06rI-00E7jd-PO for pgsql-bugs@lists.postgresql.org; Sat, 20 Sep 2025 23:19:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v06rE-001w6C-1v for pgsql-bugs@lists.postgresql.org; Sat, 20 Sep 2025 23:19:12 +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 58KNJ3B72524034; Sat, 20 Sep 2025 19:19:03 -0400 From: Tom Lane To: Christophe Pettus cc: jinhui.lai@qq.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation In-reply-to: <84B5D601-C007-4B07-9ECB-CDD06E47B949@thebuild.com> References: <19059-c751eed385314309@postgresql.org> <2510592.1758403162@sss.pgh.pa.us> <84B5D601-C007-4B07-9ECB-CDD06E47B949@thebuild.com> Comments: In-reply-to Christophe Pettus message dated "Sat, 20 Sep 2025 15:54:54 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2524032.1758410343.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 20 Sep 2025 19:19:03 -0400 Message-ID: <2524033.1758410343@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Christophe Pettus writes: > And tangentially, doesn't the SQL standard make it implementation-define= d if OR short-circuits or not? It looks like it says it's implementation-dependent, meaning that not only is it not defined by the standard, but we're not required to document it either: Subclause 6.3.3.3, =E2=80=9CRule evaluation order=E2=80=9D: a) It is implementation-dependent whether expressions are actually evaluated from left to right when the precedence is not otherwise determined by the Formats or by parentheses. b) If evaluation of the inessential parts of an expression or search condition would cause an exception condition to be raised, then it is implementation-dependent whether or not that condition is raised. c) The declared type of a site that contains an intermediate result is implementation-dependent. This is a good thing, because while we do mention boolean expression re-ordering and short-circuiting, there's an awful lot of such details that we've left undocumented. regards, tom lane