Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series) - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Date
Msg-id CAKU4AWrcp00x=QFNEZWvdTsaDewnaeN5vhXfVoLhWQYzPQ+8yw@mail.gmail.com
Whole thread Raw
In response to Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
List pgsql-hackers
Hi:
 I'd start to work on UniqueKey again, it would be great that we can target it
 to PG 15. The attached patch is just for the notnull_attrs. Since we can't say
 a column is nullable or not without saying in which resultset, so I think attaching
it to RelOptInfo is unavoidable. Here is how my patch works.

@@ -686,6 +686,12 @@ typedef struct RelOptInfo
  /* default result targetlist for Paths scanning this relation */
  struct PathTarget *reltarget; /* list of Vars/Exprs, cost, width */

+ Bitmapset **notnull_attrs; /* The attno which is not null after evaluating
+  * all the quals on this relation, for baserel,
+  * the len would always 1. and for others the array
+  * index is relid from relids.
+  */
+

For baserel, it records the notnull attrs as a bitmapset and stores it to
RelOptInfo->notnull_attrs[0].  As for the joinrel, suppose the relids is {1,3,
5}, then the notnull_attrs[1/3/5] will be used to store notnull_attrs Bitmapset
for relation 1,3,5 separately. I don't handle this stuff for all kinds of upper
relation and subquery so far since UniqueKey doesn't rely on it and looks
more stuff should be handled there.

The patch also included some debug messages in set_baserel/joinrel_notnullattrs
and attached the test.sql for easier review. Any feedback is welcome and hope 
this implementation would not block UniqueKey stuff.

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Next
From: Tom Lane
Date:
Subject: Re: Preventing abort() and exit() calls in libpq