On Thursday, July 17, 2025, David Rowley <dgrowle...@gmail.com> wrote: > > > I suggest to Greg that he might want to come up with a method to make > this configurable and a means to get something close to what we get > today and default the setting to that. It would also be easier to > follow any proposed algorithms with some example output. I used the > attached .c file to give me that. There's quite a jump in workers with > the proposed algorithm, e.g.: > > Table Size = 1024 MB old workers = 5, new workers = 12 > Table Size = 1048576 MB old workers = 11, new workers = 363 > > So I kinda doubt we could get away with such a radical change without > upsetting people that run more than 1 concurrent parallelisable query > on their server. >
Have the planner produce two numbers. 1: This plan needs a minimum of N workers to make the parallelism worthwhile. Assume that is what we produce today. 2: A number representing how much this plan would benefit from the availability of additional workers beyond the minimum. This could be the new proposed computation. The executor, seeing it has 60 workers to spare right now, is willing to allocate some percentage of them to an executing plan weighted by the value of the second number. I’d much rather avoid configuration and instead improve the executor to minimize idle parallel workers. Another approach would be a superuser (grantable) parameter that overrides planning-time heuristics and just says “use this many workers where possible”. This seems like a useful knob even if we do better with dynamic resource allocation heuristics. David J.
