Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, tomas(at)vondra(dot)me, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
Date: 2025-03-29 11:54:51
Message-ID: CAExHW5vHfy+Dqs+KcEAP_d4vSuOpNSc6W7YMVAJmeLPjOOoSKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 28, 2025 at 10:46 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2025-Mar-28, David Rowley wrote:
>
> > I experimented by applying your v4 along with 0001-0003 of Yuya's v35
> > patchset from [2]. See the attached bz2 for my results run on an AMD
> > Zen2 machine. The CREATE TABLE statement is in the attached script.
>
> Eyeballing these results, unless I am misreading them, the patch brings
> zero benefit.
>
> With PWJ off, there's no plan time improvement and no memory consumption
> improvement either; only with Watari-san's patch there's an improvement
> in plan time (and with Watari's patch, I see negligible difference
> between the case with 64 buckets and the other case, which I assume has
> 256 buckets). But the "master" vs. "v4_patch" cases seem to be
> essentially identical.
>
> With PWJ on, the situation is the same. master_pwj looks pretty much
> the same as v4_pwj.

My patch optimizes create_join_clause() which is invoked when planning
index scans. David's script does not create any indexes - implicit or
explicit. My script for example has the partition key as primary key.
So this is not surprising. If the script is modified to create the
partitioned table with the primary key, it gives similar results as
mine. That also explains why he doesn't see any changes in memory
consumption.

EC members are created irrespective of whether there are indexes or
not and Yuya's first three patches are related to ec_members handling.
So those show some improvement with David's script.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryo Kanbayashi 2025-03-29 12:19:16 Re: [PATCH] PGSERVICEFILE as part of a normal connection string
Previous Message Tatsuo Ishii 2025-03-29 11:18:09 Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options