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

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>

To: Andrei Lepikhov <lepihov@gmail.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, David Rowley <dgrowleyml@gmail.com>, Tender Wang <tndrwang@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-07-02T01:24:25Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix misuse of Relids for storing attribute numbers
- 2d756ebbe857 19 (unreleased) landed
Reduce "Var IS [NOT] NULL" quals during constant folding
- e2debb64380e 19 (unreleased) landed
Centralize collection of catalog info needed early in the planner
- 904f6a593a06 19 (unreleased) landed
Expand virtual generated columns before sublink pull-up
- e0d05295268e 19 (unreleased) landed
Expand virtual generated columns in the planner
- 1e4351af329f 18.0 cited

On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
> I like the general idea of this work. But I wonder, why is a new hash
> table designed to store only the notnullattnums field? From the
> discussion, it is not apparent why not to cache all (or most of) the
> data needed for get_relation_info. In cases where multiple subqueries
> reference the same table, it could save some cycles and memory.

I think this idea was already thoroughly discussed earlier in this
thread when Robert proposed moving get_relation_info() to an earlier
stage.  One reason against it is that not every RTE_RELATION relation
will be actively part of the query.  Collecting the whole bundle of
catalog information for such relations is wasteful and can negatively
impact performance.

Thanks
Richard