Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
Date
Msg-id CAExHW5t82tLQ9Zfmr8NQV8CJg9=ZzohGytYjtF3w6AWvMXc=yg@mail.gmail.com
Whole thread Raw
In response to Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
List pgsql-hackers


On Fri, Jul 28, 2023 at 7:28 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.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

pgsql-hackers by date:

Previous
From: Laetitia Avrot
Date:
Subject: Re: Adding a pg_servername() function
Next
From: tender wang
Date:
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails