| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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-01 13:57:18 |
| Message-ID: | 0f1d231f-4290-4eba-bd17-59920565b360@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 30/6/2025 09:26, Richard Guo wrote:
> On Wed, May 28, 2025 at 6:28 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> Yeah, this patchset is targeted for v19. Maybe we could be more
>> aggressive and have 0001 and 0002 in v18? (no chance for 0003 though)
>>
>> This patchset does not apply anymore due to 2c0ed86d3. Here is a new
>> rebase.
>
> This patchset does not apply anymore, due to 5069fef1c this time.
> Here is a new rebase.
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.
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Japin Li | 2025-07-01 14:00:22 | Re: Inconsistent LSN format in pg_waldump output |
| Previous Message | Bertrand Drouvot | 2025-07-01 13:45:55 | Re: Add os_page_num to pg_buffercache |