On Thu, 24 Jul 2025 at 08:52, Greg Hennessy <greg.henne...@gmail.com> wrote: > Adding a new enum to solve a perceived problem doesn't seem like a large > ask to me.
Seems overly slow to me. As someone has to write the patch, a committer has to commit said patch, the user must wait for the next major version to be released before upgrading their database to that version. That's 6 to 15 months at best. > Can other people give advice on if adding a new algorithm to > calculate parallel worker number and change the scaling > from log3 of a ratio to log of a GUC is best taken care of > by one patch or two? Others might be able to chime in if you gave a summary of what those patches were. I assume you want an enum GUC for the algorithm and some scale GUC? > Its clear that if we make the logarithm base an adjustable > parameter we have to insure it is not 1.0 or less, but > how much larger than 1.0 can we allow? My memory says > that the smallest floating point number larger than unity is 1+2**(-23). > I guess we can make the minimum allowed number another GUC. :) The range could be 1.0 to maybe 100.0 or 1000.0. If the number is too close to 1.0 then just have compute_parallel_worker() return max_workers. You could document 1.0 to mean "limit to max_parallel_maintenance_workers / max_parallel_workers_per_gather". The function won't return a value higher than that anyway. David
