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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: 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-07-02 09:14:48
Message-ID: CAMbWs4-R5PWEJ7Ze_ZL30c7cA+87FeDK4YAmC7Zv1tsao2ObpQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 2, 2025 at 4:32 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> I must say that I appreciate Tom's idea and see significant benefits in
> making the parse tree a read-only structure. In complex queries, it can
> be frustrating to make copies of the parse tree, leading to complaints
> from users about insufficient memory allocation. This is why, in our
> enterprise fork, we support a specific option to avoid copying the parse
> tree multiple times.

I don't see how the changes in this patchset violate Tom's proposal
regarding keeping the parse tree read-only. The only potential issue
I can see is that we may clear the rte->inh flag in some cases -- but
that behavior has existed for a long time, not starting from this
patchset.

> Therefore, it would be better to find a way to refactor the
> `preprocess_relation_rtes` function to gather table statistics lazily
> into the hash table when they are needed. For example, we could do this
> at the moment of creating the `RelOptInfo` or before a subquery pull-up,
> without modifying the RTE at all.

All the catalog information collected in preprocess_relation_rtes() is
needed very early in the planner. I don't see how we could move that
logic to a later stage, such as at the moment of creating RelOptInfos
as you mentioned.

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-07-02 09:18:00 Re: pg_restore --no-policies should not restore policies' comment
Previous Message Bertrand Drouvot 2025-07-02 09:03:35 Re: A assert failure when initdb with track_commit_timestamp=on