David Rowley <dgrowleyml@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
