In continuation with the previous mail (CAAh00ETEMEXntw1gxp=xP+4sqrz80tK1R4VEhTpqH9CJpxs-wA) regarding the optimizations in PostgreSQL 18 to simplify query plans by folding away Var IS [NOT] NULL checks on columns declared NOT NULL. I experimented with two approaches, but both hit significant errors:
The idea was to collect NOT NULL constraint info early and use it for constant folding.
gen_node_support.plcannot handle non-serializable HTAB* fields when generating node serialization code, leading to compilation errors (“could not handle type HTAB*”).
Workarounds (e.g., /* nonserialized */ comments) fail due to comment stripping, and marking the whole PlannerInfo with pg_node_attr(no_copy_equal, no_read_write) risks breaking features like parallel query execution or plan caching.
Other limitations include potential ABI stability issues from modifying node structs, increased memory usage from hash tables in nodes, and the preference for per-relation data structures (e.g., in RelOptInfo) over global ones.
A global hash table is a viable alternative but complicates subquery handling.
2. Planner-level relattrinfo_htab for column nullability
This avoids touching node serialization, but still suffers from practical issues.
It crashes during initdb because catalog state is unavailable in bootstrap mode, requires fragile lifecycle management to avoid memory leaks or stale entries which leads to risking leaks or stale state, and largely duplicates the existing var_is_nonnullable() logic.
In practice, it yields minimal performance benefit since constant folding and nullability inference are largely handled in core
I’d appreciate feedback on whether pursuing either direction makes sense, or whether improvements should instead focus on extending the existing var_is_nonnullable() framework.
On Mon, Sep 8, 2025 at 10:08 PM Junwang Zhao <zhjwpku@gmail.com> wrote: > On Mon, Sep 8, 2025 at 4:21 PM Richard Guo <guofenglinux@gmail.com> wrote: > > Your patch misses one spot: the notnullattnums in > > get_relation_notnullatts() should also be fixed. Otherwise it LGTM.
> True, attached v2 adds that missing spot, thanks for the review.
