Re: Reduce "Var IS [NOT] NULL" quals during constant folding

From: BharatDB <bharatdbpg(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Junwang Zhao <zhjwpku(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tender Wang <tndrwang(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Reduce "Var IS [NOT] NULL" quals during constant folding
Date: 2025-09-18 12:46:02
Message-ID: CAAh00EQwkjsLwiCh5r5jBSXjyE-hWhisARuM92O1OZRz4Mi0TQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Team,

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:

*1. PlannerInfo-level hash table (HTAB *rel_notnull_info)*

- The idea was to collect NOT NULL constraint info early and use it for
constant folding.
- gen_node_support.pl cannot 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.

Sincerely,
Soumya

On Fri, Sep 12, 2025 at 7:51 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:

> On Mon, Sep 8, 2025 at 10:08 PM Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
> > On Mon, Sep 8, 2025 at 4:21 PM Richard Guo <guofenglinux(at)gmail(dot)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.
>
> Pushed. Thanks for the report and fix.
>
> - Richard
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2025-09-18 13:26:30 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Daniel Gustafsson 2025-09-18 12:43:52 Re: someone else to do the list of acknowledgments