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.96) (envelope-from ) id 1wNn4G-0013yk-0S for pgsql-hackers@arkaria.postgresql.org; Fri, 15 May 2026 07:34:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wNn4D-00H4la-1i for pgsql-hackers@arkaria.postgresql.org; Fri, 15 May 2026 07:34:41 +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.96) (envelope-from ) id 1wNn4D-00H4lS-0o for pgsql-hackers@lists.postgresql.org; Fri, 15 May 2026 07:34:41 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wNn4B-00000000fKw-1RL3 for pgsql-hackers@postgresql.org; Fri, 15 May 2026 07:34:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=jfpj1b/bUAPwoidllXd6JI5mmrDKR9JA5tNH/WHYcLM=; b=Hw1VPcnx2U5+AytL0eH1mgeGZX 0dchMtT77RNKPb67WY6AnjYmBJT/gJhIrJbNCbCavsrVxdwf5VQvB2jXwvvWEp7/dGZKVbWrAtbng c3sX0GItyT/cyGMTxQUbdckKfVeegTraoII/aH+sc2ZOZJTFIC4E6FhtektzK5MVfIICVTXpTQfy2 CFAN7yFf64YZCSCyBUOgNXvHrV8us42QLP6cVxh1Wq7W9M6iMAr46RXbGn5N9OtT3w9B0/waH2912 u5oJVmt7MXdfJHlCDsE9P4ySvazNsVEfvj60ryGl20eftWlYB0dUt9xvQQl437rO5vovBbzIOript 83ZAazNw==; Received: from [2409:11:4120:300:356:9771:dcdb:d832] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wNn47-001oqb-2u; Fri, 15 May 2026 07:34:38 +0000 Date: Fri, 15 May 2026 16:34:25 +0900 (JST) Message-Id: <20260515.163425.1708559652740041584.ishii@postgresql.org> To: li.evan.chao@gmail.com Cc: pgsql-hackers@postgresql.org, ojford@gmail.com Subject: Re: Should IGNORE NULLS cache nullness for volatile arguments? From: Tatsuo Ishii In-Reply-To: References: <20260514.165323.1913944269609196803.ishii@postgresql.org> <20260514.215622.2237422742023167912.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:356:9771:dcdb:d832 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk >> @@ -3454,7 +3455,10 @@ ignorenulls_getfuncarginframe(WindowObject winobj, int argno, >> if (isout) >> *isout = false; >> >> - v = get_notnull_info(winobj, abs_pos, argno); >> + if (winobj->notnull_info_cacheable[argno]) >> >> What about moving this if statement inside get_notnull_info() so that >> the caller does not care about this argno is cacheable or not? >> >> + /* record the row status if it is safe to reuse */ >> + if (winobj->notnull_info_cacheable[argno]) >> + put_notnull_info(winobj, abs_pos, argno, *isnull); >> >> Similary, we can move "if (winobj->notnull_info_cacheable[argno])" inside put_notnull_info(). >> > > Yep, good idea. Addressed in attached v2. Thanks for the v2 patch. It looks good to me. I am going to push the patch within a few days if there's no objection. Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp