I don't think having a GUC which allows exactly two settings is
anywhere near as flexible as you could make this.
I would phrase it as being a GUC with two settings currently,
I think it is easier to go from 2 possible algorithms to 3 than
it is to go from 1 to 2.
You're complaining
that the current calculation isn't ideal for you and are proposing a
new one which seemingly is more to your liking, but who's to say that
someone else would find either useful? With this method, if someone
else comes along complaining, do we give them what they want by adding
a new enum? That does not sound great :(
Adding a new enum to solve a perceived problem doesn't seem like a large
ask to me. If you think this situation isn't great, may I ask what you would
consider great?
One thought I had was that you could adjust the "divide by 3" to be
"divide by <some_new_GUC>" and make that calculation floating point.
I would think that a new patch to change the hard coded log3 to a more general
log(x) where X is controlled by a GUC would be better solved by a separate
patch, but I have no objection to submitting a new patch that includes that.
On rethink, maybe you can use the log() function to get something
close to what's being generated today.
I think the ceil function needs to be in there to exactly match the existing
behavior, but I haven't verified. I do agree that having the default
behavior not change unless set by an admin to be a good idea.
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?
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. :)
