Re: simple patch for discussion

On Thu, 24 Jul 2025 at 08:52, Greg Hennessy <greg(dot)hennessy(at)gmail(dot)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