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