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 1wNVcM-000rYf-24 for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2026 12:56:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wNVcL-00CCLT-19 for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2026 12:56:45 +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.96) (envelope-from ) id 1wNVcL-00CCLK-0D for pgsql-hackers@lists.postgresql.org; Thu, 14 May 2026 12:56:45 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wNVcI-00000000ZcX-1cBW for pgsql-hackers@postgresql.org; Thu, 14 May 2026 12:56:44 +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=ibCjFfTXJPjdqOIJ3RYDu3UdpScIgj2YUF9KDSan2DQ=; b=qdKh6YY3SIEMmCx7Ng3XSnSEPI YHHXaReBlicrYgNfS73/lYUKJuf8KAok1RcQdzIxj19Id9sfOng8cPOX8YzLR8h+nL7Wy/0RPx11R fbqr3SDzob03IIE7jWuRgDKB1SsZYtSO96IOwW8cqnZqpvwTRUO42w4ymTb8dn0iASC5anCGaZv8m EwcyLO1VWZBm5+UFL/7NCF4wFcbyjD/11tlW9xN58EpveSq12EkcrzHNvNHIltM5U0A+lW3sKGcLo MRzuCcKe0wYEpkieLxIVAAA3HvDgWnQJBWK/eKv2Jz7puDAOF/vCyXphJgQttipxAqAIcq9zAbXjh IkiYXXrQ==; Received: from [2409:11:4120:300:ed7b:4abe:8d2a:f357] (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 1wNVcF-001UC8-34; Thu, 14 May 2026 12:56:42 +0000 Date: Thu, 14 May 2026 21:56:22 +0900 (JST) Message-Id: <20260514.215622.2237422742023167912.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: <20260514.165323.1913944269609196803.ishii@postgresql.org> References: <42B42506-6972-4266-8422-FB73E61D9DA7@gmail.com> <20260514.165323.1913944269609196803.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:ed7b:4abe:8d2a:f357 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Chao, >> The attached patch makes a small change in that direction. It only uses the IGNORE NULLS nullness cache when the argument is safe to reuse. For non-cacheable arguments, the nullness is treated as unknown and the argument is evaluated again. >> >> See the attached patch for details. > > I will look into the patches. @@ -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(). Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp