From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: David Rowley <drowley@postgresql.org>, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add better handling of redundant IS [NOT] NULL quals
In-reply-to: <202401231915.uwk6zrqbdvsu@alvherre.pgsql>
References: <202401231915.uwk6zrqbdvsu@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 23 Jan 2024 20:15:38 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4071561.1706038734.1@sss.pgh.pa.us>
Date: Tue, 23 Jan 2024 14:38:54 -0500
Message-ID: <4071562.1706038734@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4071562.1706038734%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2024-Jan-23, David Rowley wrote:
>> Until now PostgreSQL has not been very smart about optimizing away IS
>> NOT NULL base quals on columns defined as NOT NULL.

> Hmm, what happens if a NOT NULL constraint is dropped and you have such
> a plan in plancache?  As I recall, lack of a mechanism to invalidate
> such plans was the main reason for Postgres not to have this.

IIRC, we realized that that concern was bogus.  Removal of such
constraints would cause pg_attribute.attnotnull to change, leading
to a relcache invalidation on the table, forcing replan.  If anyone
tried to get rid of attnotnull or make it incompletely reliable,
then we'd have problems; but AFAIK that's not being contemplated.

			regards, tom lane