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

Поиск
Список
Период
Сортировка
От BharatDB
Тема Re: Reduce "Var IS [NOT] NULL" quals during constant folding
Дата
Msg-id CAAh00EQwkjsLwiCh5r5jBSXjyE-hWhisARuM92O1OZRz4Mi0TQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reduce "Var IS [NOT] NULL" quals during constant folding  (Richard Guo <guofenglinux@gmail.com>)
Список 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@gmail.com> wrote:
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.

Pushed.  Thanks for the report and fix.

- Richard


В списке pgsql-hackers по дате отправления: