Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

Hi Ashutosh,

On Wed, Aug 16, 2023 at 2:28 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> On Fri, Aug 4, 2023 at 2:11 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> >
> > 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.
>
> 0003 - Added this patch for handling SpecialJoinInfos for inner joins.
> These SpecialJoinInfos are created on the fly for parent joins. They
> can be created on the fly for child joins as well without requiring
> any translations. Thus they do not require any new memory. This patch
> is intended to be merged into 0002 finally.

I read this thread and have been reading the latest patch. At first
glance, it seems quite straightforward to me. I agree with Richard
that pfree()'ing 4 bitmapsets may not be a lot of added overhead. I
will study the patch a bit more.

Just one comment on 0003:

+ /*
+ * Dummy SpecialJoinInfos do not have any translated fields and hence have
+ * nothing to free.
+ */
+ if (child_sjinfo->jointype == JOIN_INNER)
+ return;

Should this instead be Assert(child_sjinfo->jointype != JOIN_INNER)?

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com