Horton

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

Dmitry Dolgov <9erthalion6@gmail.com>

View thread
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: tomas@vondra.me, vignesh C <vignesh21@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Richard Guo <guofenglinux@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2025-02-21T11:07:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add assertion to verify derived clause has constant RHS

  2. Make derived clause lookup in EquivalenceClass more efficient

  3. Doc: improve documentation for jsonpath behavior.

  4. Work around implementation restriction in adjust_appendrel_attrs.

> 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.