| 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 01:24:25 |
| Message-ID: | CAMbWs49qYP2p0pJYeXVxuNfL-eX24v1jPgU4JjkDbnkQ4ujwbw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov <lepihov(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Fan | 2025-07-02 01:38:18 | Re: A assert failure when initdb with track_commit_timestamp=on |
| Previous Message | Michael Paquier | 2025-07-02 00:55:22 | Re: [PATCH] Split varlena.c into varlena.c and bytea.c |