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: Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Richard Guo <guofenglinux(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
Date: 2024-03-22 10:48:38
Message-ID: CAExHW5vQ2HyZsZypejfVwWEAv2sPOnecQozihZJBky2A0-1S9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 22, 2024 at 2:54 PM Amit Langote <amitlangote09(at)gmail(dot)com>
wrote:

> >
> > Please let me know if you need anything.
>
> Thanks for repeating the benchmark. So I don't see a problem with
> keeping the existing palloc() way of allocating the
> SpecialJoinInfos(). We're adding a few cycles by adding
> free_child_join_sjinfo() (see my delta patch about the rename), but
> the reduction in memory consumption due to it, which is our goal here,
> far outweighs what looks like a minor CPU slowdown.
>
> I have squashed 0002, 0003 into 0001, done some changes of my own, and
> attached the delta patch as 0002. I've listed the changes in the
> commit message. Let me know if anything seems amiss.
>
> Thanks Amit for your changes.

> * Revert (IMO) unnecessary modifications of build_child_join_sjinfo().
> For example, hunks to rename sjinfo to child_sjinfo seem unnecessary,
> because it's clear from the context that they are "child" sjinfos.
>

Ok.

> * Rename free_child_sjinfo_members() to free_child_join_sjinfo() to
> be symmetric with build_child_join_sjinfo(). Note that the function
> is charged with freeing the sjinfo itself too. Like
> build_child_join_sjinfo(), name the argument sjinfo, not
> child_sjinfo.

Yes. It should have been done in my patch.

>
> * Don't set the child sjinfo pointer to NULL after freeing it. While
> a good convention in general, it's not really common in the planner
> code, so doing it here seems a bit overkill

That function is the last line in the block where pointer variable is
declared.
As of now there is no danger of the dangling pointer being used.

>
> * Rename make_dummy_sjinfo() to init_dummy_sjinfo() because the
> function is not really making it per se, only initializing fields
> in the SpecialJoinInfo struct made available by the caller.

Right.

>
> * Make init_dummy_sjinfo() take Relids instead of RelOptInfos because
> that's what's needed. Also allows to reduce changes to
> build_child_join_sjinfo()'s signature.

I remember, in one of the versions it was Relids and then I changed to
RelOptInfos for some reason. The latest version seems to use just Relids. So
this looks better.

>
> * Update the reason mentioned in a comment in free_child_join_sjinfo()
> about why semi_rhs_expr is not freed -- it may be freed, but there's
> no way to "deep" free it, so we leave it alone.
>
> * Update a comment somewhere about why SpecialJoinInfo can be
> "transient" sometimes.

With the later code, semi_rhs_expr is indeed free'able. It wasn't so when I
wrote the patches. Thanks for updating the comment. I wish we would have
freeObject(). Nothing that can be done for this patch.

Attached patches
Squashed your 0001 and 0002 into 0001. I have also reworded the commit
message to reflect the latest code changes.
0002 has some minor edits. Please feel free to include or reject when
committing the patch.

--
Best Wishes,
Ashutosh Bapat

Attachment Content-Type Size
0002-Minor-edits-20240322.patch text/x-patch 1.8 KB
0001-Reduce-memory-used-by-child-SpecialJoinInfo-20240322.patch text/x-patch 10.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Viliam Ďurina 2024-03-22 11:26:27 MIN/MAX functions for a record
Previous Message Amit Kapila 2024-03-22 10:46:19 Re: Introduce XID age and inactive timeout based replication slot invalidation