Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q4iiU-0002gr-5i for pgsql-bugs@arkaria.postgresql.org; Thu, 01 Jun 2023 13:51:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q4iiS-00064E-H8 for pgsql-bugs@arkaria.postgresql.org; Thu, 01 Jun 2023 13:51:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q4iiS-00063S-8o for pgsql-bugs@lists.postgresql.org; Thu, 01 Jun 2023 13:51:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q4iiO-003VNm-Pk for pgsql-bugs@lists.postgresql.org; Thu, 01 Jun 2023 13:51:47 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 351DpbDX3190676; Thu, 1 Jun 2023 09:51:38 -0400 From: Tom Lane To: "Ken McClaren" cc: "Wetmore, Matthew (CTR)" , "pgsql-bugs@lists.postgresql.org" , John Hall Subject: Re: Order of operations in postgreSQL. In-reply-to: References: <668989cd22e8457ca7a85d0e74c34bde@express-scripts.com> Comments: In-reply-to "Ken McClaren" message dated "Thu, 01 Jun 2023 00:21:01 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3844.1685627497.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 01 Jun 2023 09:51:37 -0400 Message-ID: <3845.1685627497@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Ken McClaren" writes: > Yes, the error is correct, but it should never have occurred. > The join should have eliminated the error condition before it was evalua= ted by the where clause. That is the case when this type of statement is e= xecuted in SQL Server. Postgres does not promise that JOIN conditions are evaluated before WHERE conditions. I rather doubt that SQL Server does either, because it'd cripple performance for a lot of real-world queries. If you need something like that, you should restructure the query into two levels with an optimization fence between them. One way is SELECT ... FROM (SELECT ... FROM t1 JOIN t2 ON join-condition OFFSET 0) ss WHERE risky-where-condition regards, tom lane