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

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: 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>, David Rowley <dgrowleyml(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
Date: 2025-02-21 11:07:25
Message-ID: jgjl7cp34yzumfppgqrly2p23soatjg4bk36hk4sjjz5bowiv6@5h3tj2uf6yx6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mon, Nov 25, 2024 at 11:20:05AM GMT, Ashutosh Bapat wrote:
> > I've tried to reproduce some subset of those results, in case if I would
> > be able to notice anything useful. Strangely enough, I wasn't able to
> > get much boost in planning time e.g. with 4 first patches, 100
> > partitions and 5 joins -- the results you've posted are showing about
> > 16% in that case, where I'm getting only a couple of percents. Probably
> > I'm doing something differently, but it's turned out to be hard to
> > reconstruct (based only on this thread) how did you exactly benchmark
> > the patch -- could you maybe summarize the benchmark in a reproducible
> > way?
>
> Hmm, I am doing something similar to what you are doing. Here are my scripts.
> setup.sql - creates partitioned table, and functions, tables used to
> run the benchmark
> benchmark.sh - creates queries with all combinations of
> enable_partitionwise_join, number of partitions, joins etc. and runs
> EXPLAIN on each query recording the results in a table.
> run_bm_on_commits.sh - runs setup.sql once, then runs benchmark.sh on
> each commit (using git rebase) and finally outputs the average numbers
> to be fed to the "aggregate numbers" sheet.

Just FYI, I've finally found time to figure out why do I get slightly
different results. It turns out I was running tests against a
partitioned table without a primary key, which obviously affects
planner, making planning time shorter and reducing the delta between the
patched version and the main branch.

But of course a partitioned table without a pk makes little sense, so I
guess those results are not very relevant. I've done another round with
pk, and got results similar to yours.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2025-02-21 11:29:12 Re: Missing [NO] INDENT flag in XMLSerialize backward parsing
Previous Message Nitin Jadhav 2025-02-21 10:59:27 Fix crash during recovery when redo segment is missing