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

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>

To: Tomas Vondra <tomas@vondra.me>

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-30T07:55:43Z

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 Wed, Jul 30, 2025 at 3:17 PM Richard Guo <guofenglinux@gmail.com> wrote:
> create table t (a int, b int, c int);
>
> explain (costs off)
> select * from t t1
>  natural join t t2
>  natural join t t3
>  natural join t t4
>  natural join t t5
>  natural join t t6
>  natural join t t7
>  natural join t t8
>  natural join t t9
>  natural join t t10
> ;

FWIW, for this query, I've observed that table_open/table_close are
also called for each RTE_RELATION in build_physical_tlist().  Not sure
if we should also be concerned about those calls.

It's not clear to me how much performance impact an extra table_open
might have, especially when the lock is already held, and the relation
is likely present in the relcache.

Thanks
Richard