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 1pAqca-0006Xh-5u for pgsql-bugs@arkaria.postgresql.org; Thu, 29 Dec 2022 10:58:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pAqcX-0002mc-HF for pgsql-bugs@arkaria.postgresql.org; Thu, 29 Dec 2022 10:58:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pAqcX-0002mT-7W for pgsql-bugs@lists.postgresql.org; Thu, 29 Dec 2022 10:58:45 +0000 Received: from mx0b-00134001.pphosted.com ([205.220.172.129]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pAqcR-0001KS-2P for pgsql-bugs@lists.postgresql.org; Thu, 29 Dec 2022 10:58:43 +0000 Received: from pps.filterd (m0267961.ppops.net [127.0.0.1]) by mx0a-00134001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BTASwGj031687 for ; Thu, 29 Dec 2022 10:58:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=optiver.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=mail; bh=f20hLdai0zBKF1+NO5Q0GoHD7Z9yuaJU2M1pZ9jYLEw=; b=uJmDChUEgJOyfOJu9IG9EIzCY1KEPFWJ6YGyUFRsLuuNuEFVL4uGmHzHAJmOwnAJ8s9l lbSEIwWZXxUW7moI0ryFfUPi4kD9cIOlbIQg7q/lQBQFPByKdpdj8TVzs98jrYLJ3XWZ tVr8gQAXYvvNI1ZCyRIi36U1h2+3lx7YjIJjuhy1sxIKRKv0TDSPeiiH2Cntn0a2pxXj Cm1v02oe/YSCEjbbMtQAYimONS/d0oc8rN9Q9O9IOIRb0QmgCGjsZdN2b3Y07Nv5Z9sK darQ8ddojuZ3Ejmr+Mj+ZhNqy/eC+HE3R0EpLU3z5EK8vSTnDJqKPdH97Lpt/uLF1kgl fA== Received: from opammb0561.comp.optiver.com ([195.246.114.117]) by mx0a-00134001.pphosted.com (PPS) with ESMTPS id 3mnpw1kx9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 29 Dec 2022 10:58:37 +0000 Received: from opammb0562.comp.optiver.com (10.131.160.2) by opammb0561.comp.optiver.com (10.131.160.1) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Thu, 29 Dec 2022 11:58:35 +0100 Received: from opammb0562.comp.optiver.com ([fe80::a1fd:9274:f7b1:98ca]) by opammb0562.comp.optiver.com ([fe80::a1fd:9274:f7b1:98ca%17]) with mapi id 15.00.1497.040; Thu, 29 Dec 2022 11:58:35 +0100 From: Floris Van Nee To: "pgsql-bugs@lists.postgresql.org" Subject: postgres reorders expressions when inlining Thread-Topic: postgres reorders expressions when inlining Thread-Index: AdkbcKQk26ojlcUsTtKsiI8Z2XOueQ== Date: Thu, 29 Dec 2022 10:58:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.160.182] x-tm-as-product-ver: SMEX-14.0.0.3031-9.0.1002-27352.007 x-tm-as-result: No-10--10.606100-5.000000 x-tmase-matchedrid: 2mVTIgh7BvF4GcCqxQcAiDxKEn0iLGa7PYWAASIMdr8Ff2cKXhyij/0K H6Ri/xJpH/BqsMqA1XR/TESe/R6s+k/qR+K9xHrRD/of1psMgxEEa8g1x8eqFw6QlBHhBZuwCeW hs1FY/qWbtw2XfFPBnPeO+s8PB0TAJPwGIy6fSEzmOliryhGWU+uLFZZYlisfv1l2Uvx6idoLbi gRnpKlKTpcQTtiHDgW8J/1z4SwRpyHSaioFmyava1f+VjAUQ3HZrlMUWbWzJ/9F431HqE8PQ== x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--10.606100-5.000000 x-tmase-version: SMEX-14.0.0.3031-9.0.1002-27352.007 x-tm-snts-smtp: B487CBE869233E0396006AADA75EA3A8DCCE0BECB62E226E086BE90541B6586B2000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-29_06,2022-12-29_01,2022-06-22_01 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi hackers, I recently ran into some behavior with inlining that seemed strange to me. = I managed to break it down into a small reproducible example that I've adde= d. I originally ran into it in more complicated queries that involved inlin= ing of SQL functions instead of subqueries, but it reproduces with subqueri= es too so that's the example I've added. Tested on v15. create table t1 as select a, b from generate_series(0, 5) a, generate_serie= s(0, 10) b; select * from ( select a, b, c from t1 left join lateral ( select 1 / b as c ) c on true where b <> 0 ) as o where o.c is not null The SELECT query leads to a division by zero. Plan: Seq Scan on t1 Filter: (((1 / b) IS NOT NULL) AND (b <> 0)) Postgres seems to decide that it's smart to execute the "o.c is not null" c= heck before checking if b is 0. However, this obviously leads to division b= y 0. In many other cases (for example not using left join lateral but inste= ad putting the calculation straight into the SELECT of the subquery), Postg= res does the right thing and checks for 0 first. Also, forcefully disabling= inlining (by adding "offset 0" to the subquery for example) makes the quer= y execute correctly. Is it expected that Postgres reorders these expressions? I'd think that, ev= en though Postgres decides to inline a query, it should at least evaluate t= he expressions of the inner-part before the outer part to avoid the divisio= n by zero. -Floris