Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
Date
Msg-id CA+HiwqHkQ4uuDd0=N00kHmPa9tKzSz6PwyaqZwBmFZ4R8ex5vA@mail.gmail.com
Whole thread Raw
In response to Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
List pgsql-hackers
On Thu, Apr 3, 2025 at 12:28 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Wed, Apr 2, 2025 at 9:52 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> > On Wed, Apr 2, 2025 at 1:00 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > > I'm feeling good about this version, but let me know if you have any
> > > further thoughts / comments.
> >
> > Thanks for incorporating the changes and fixing initial hash table size.
> >
> > + #define EC_DERIVES_HASH_THRESHOLD 32
> >
> > Given that the constant is being used only at a single place, we don't
> > need a macro. But I am not against the macro.
>
> Yeah, let's keep it, because it documents well.
>
> > PFA patch set with some minor edits in 0003. Also I have edited commit
> > message of 0001 and 0002.
> >
> > In the commit messages of 0002,
> > 1. mentioning that the lookup happens only for join clause generation
> > is not accurate, since we lookup EM = constant clauses as well which
> > are not join clauses.
> > 2. In the second paragraph em1 and em2 are mentioned without
> > mentioning what are they. I have rephrased it so as to avoid
> > mentioning names of structure member.
>
> Incorporated, thanks.
>
> I'll plan to commit these tomorrow barring objections.

I’ve now marked this as committed after pushing the patches earlier today.

I realize the CF entry was originally about the project to reduce
memory usage during partitionwise join planning, but we ended up
committing something else. I suppose we can create a new entry if and
when we pick that original work back up.

--
Thanks, Amit Langote



pgsql-hackers by date:

Previous
From: m.litsarev@postgrespro.ru
Date:
Subject: Re: pg_stat_statements: improve loading and saving routines for the dump file
Next
From: Andrei Lepikhov
Date:
Subject: Re: Removing unneeded self joins