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