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 1tdZGP-0089vJ-BW for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Jan 2025 18:27:41 +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 1tdZGO-00CoIf-Dx for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Jan 2025 18:27:40 +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 1tdZGO-00CoIX-4q for pgsql-hackers@lists.postgresql.org; Thu, 30 Jan 2025 18:27:40 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tdZGM-002KZw-0L for pgsql-hackers@lists.postgresql.org; Thu, 30 Jan 2025 18:27:39 +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 50UIRWuo3346422; Thu, 30 Jan 2025 13:27:33 -0500 From: Tom Lane To: Heikki Linnakangas cc: Xing Guo , Andreas Karlsson , pgsql-hackers@lists.postgresql.org Subject: Re: JIT: The nullness of casetest.value can be determined at the JIT compile time. In-reply-to: <3070951.1738207772@sss.pgh.pa.us> References: <1c767ec4-709e-45b1-bc0e-add024326e77@iki.fi> <3070951.1738207772@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 29 Jan 2025 22:29:32 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3346420.1738261652.1@sss.pgh.pa.us> Date: Thu, 30 Jan 2025 13:27:32 -0500 Message-ID: <3346421.1738261652@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Agreed. I spent some time trying to do it better, with results > shown at [1]. If we adopt that idea, then the executor's support > for CaseTestExpr will go away, so there's little point in pursuing > that half of the patch given here. However, I concluded that there's > insufficient reason to redesign CoerceToDomainValue, so we could > still push forward with that half of this patch. On further consideration, we might as well do this whole patch. The patch I'm proposing over there is large and might well not land in v18 (or ever), so let's get this low-hanging fruit. I pushed Andreas's patch with some cosmetic tidying, mainly that I felt it better not to try to combine duplicate-ish code for the EEOP_CASE_TESTVAL and EEOP_DOMAIN_TESTVAL cases. We're after understandability here after all, and it's still a net code savings even with that duplication. regards, tom lane