Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
Date: 2023-09-20 13:24:37
Message-ID: CAExHW5uP0j31722TmkhZRav5wdB+xyW649opRH9h_Y6aPMnC_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 20, 2023 at 5:24 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> 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.

Thanks.

>
> 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)?

try_partitionwise_join() calls free_child_sjinfo_members()
unconditionally i.e. it will be called even SpecialJoinInfos of INNER
join. Above condition filters those out early. In fact if we convert
into an Assert, in a production build the rest of the code will free
Relids which are referenced somewhere else causing dangling pointers.

--
Best Wishes,
Ashutosh Bapat

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2023-09-20 13:29:52 Re: Infinite Interval
Previous Message Amul Sul 2023-09-20 12:58:36 Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).