On Fri, 4 Jan 2019 at 02:40, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > I'm a bit confused, because I can't reproduce any such speedup. I've > used the attached script that varies the number of partitions (which > worked quite nicely in the INSERT thread), but I'm getting results like > this: > > partitions 0 100 1000 10000 > -------------------------------------------- > master 49 1214 186 11 > patched 53 1225 187 11 > > So I don't see any significant speedup, for some reason :-( > > Before I start digging into this, is there something that needs to be > done to enable it?
Thanks for looking at this. One thing I seem to quite often forget to mention is that I was running with: plan_cache_mode = force_generic_plan max_parallel_workers_per_gather = 0; Without changing plan_cache_mode then the planner would likely never favour a generic plan since it will not appear to be very efficient due to the lack of consideration to the costing of run-time partition pruning. Also, then with a generic plan, the planner will likely want to build a parallel plan since it sees up to 10k partitions that need to be scanned. max_parallel_workers_per_gather = 0 puts it right. (Ideally, the planner would cost run-time pruning, but it's not quite so simple for RANGE partitions with non-equality operators. Likely we'll want to fix that one day, but that's not for here) -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services