David Rowley <dgrowle...@gmail.com> writes: > I quickly put together the attached patch which adds a "knownnotnull" bool > field to Var which we can set to true when we're completely sure that the > Var cannot contain any NULL values.
This is utterly the wrong way to go about it. How will you update views containing such Vars, when someone does an ALTER TABLE SET/DROP NOT NULL? The right thing is for the planner to look *at plan time* to see if the column is marked NOT NULL. (This is safe against the ALTER TABLE problem because an ALTER will result in a relcache invalidation signal, forcing any plans referencing the table to be regenerated before next use.) One way to go about it would be to add a bool array to RelOptInfo and teach plancat.c to populate the array. However, that would only be a win if we could expect the information to get used (preferably multiple times) in most planning attempts. That does not seem to me to be likely for this use case, so I'd go with just doing a pg_attribute catcache lookup on-the-fly when necessary. I'd suggest (1) new lsyscache.c utility function taking a relation OID and an attnum; (2) new function somewhere in the planner that decides whether an expression is known not-null. For a Var, it'd fetch the matching RTE, see if it's RTE_RELATION, and if so call the lsyscache.c function. There are a lot of other potential cases that such a function could be taught about later, if it proves useful. BTW, you'd need to be pretty careful about semantics here. Even if the Var is known not-null at the point of scanning the relation, what if that relation is nullable by some upper outer join? Perhaps the function (2) would need to take an argument describing the join level at which we're making the test. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers