Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
Date: 2023-08-04 08:41:56
Message-ID: CAExHW5t82tLQ9Zfmr8NQV8CJg9=ZzohGytYjtF3w6AWvMXc=yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 28, 2023 at 7:28 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> >
> > + bms_free(child_sjinfo->commute_above_l);
> > + bms_free(child_sjinfo->commute_above_r);
> > + bms_free(child_sjinfo->commute_below_l);
> > + bms_free(child_sjinfo->commute_below_r);
> >
> > These four members in SpecialJoinInfo only contain outer join relids.
> > They do not need to be translated. So they would reference the same
> > memory areas in child_sjinfo as in parent_sjinfo. We should not free
> > them, otherwise they would become dangling pointers in parent sjinfo.
> >
>
>
Attached patchset fixing those.
0001 - patch to report planning memory, with to explain.out regression
output fix. We may consider committing this as well.
0002 - with your comment addressed above.

>
> I think we should 1. add an assert to make sure that commute_above_*
> do not require any transations i.e. they do not contain any parent
> relids of the child rels.

Looking at the definitions of commute_above and commute_below relids and OJ
relids, I don't think these assertions are necessary. So didn't add those.

> 2. Do not free those.

Done

> 3. Add a comment about
> keeping the build and free functions in sync.
>

Done.

--
Best Wishes,
Ashutosh Bapat

Attachment Content-Type Size
0002-Reduce-memory-used-by-child-SpecialJoinInfo-20230804.patch text/x-patch 6.7 KB
0001-Report-memory-used-for-planning-a-query-in--20230804.patch text/x-patch 10.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tender wang 2023-08-04 09:04:29 Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Previous Message Laetitia Avrot 2023-08-04 08:26:46 Re: Adding a pg_servername() function