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

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>

To: Richard Guo <guofenglinux@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>

Cc: 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-01T13:57:18Z

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 30/6/2025 09:26, Richard Guo wrote:
> On Wed, May 28, 2025 at 6:28 PM Richard Guo <guofenglinux@gmail.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