Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

On Fri, Apr 4, 2025 at 2:04 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> On Thu, Apr 3, 2025 at 12:28 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Wed, Apr 2, 2025 at 9:52 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > > On Wed, Apr 2, 2025 at 1:00 PM Amit Langote <amitlangote09(at)gmail(dot)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.

Thanks a lot.

>
> 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.

Will create a new CF entry just to keep the patch floated.

--
Best Wishes,
Ashutosh Bapat