Hello Robert,
I've looked at the maths.
I think that the load is distributed as the derivative of this
function, that is (1.5 * x ** 0.5): It starts at 0 but very quicky
reaches 0.5, it pass the 1.0 (average load) around 40% progress, and
ends up at 1.5, that is the finishing load is 1.5 the average load,
just before fsyncing files. This looks like a recipee for a bad time: I
would say this is too large an overload. I would suggest a much lower
value, say around 1.1...
The other issue with this function is that it should only degrade
performance by disrupting the write distribution if someone has WAL on
a different disk. As I understand it this thing does only make sense if
the WAL & the data are on the samee disk. This really suggest a guc.
I am a bit skeptical about this. We need test scenarios that clearly
show the benefit of having and of not having this behavior. It might be
that doing this always is fine for everyone.
Do you mean I have to proove that there is an actual problem induced from
this patch?
The logic fails me: I thought the patch submitter would have to show that
his/her patch did not harm performance in various reasonable cases. At
least this is what I'm told in another thread:-)
Currently this patch changes heavily the checkpoint write load
distribution in many cases with a proof which consist in showing that it
may improve tps *briefly* on *one* example, as far as I understood the
issue and the tests. If this is enough proof to apply the patch, then the
minimum is that it should be possible to desactivate it, hence a guc.
Having a guc would also help to test the feature with different values
than 1.5, which really seems harmful from a math point of view. I'm not
sure at all that a power formula is the right approach.
The potential impact I see would be to aggravate significantly the write
stall issues I'm working on, but the measures provided in these tests do
not even look at that or measure that.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
