Re: Improvement of checkpoint IO scheduler for stable transaction responses
От | Ants Aasma |
---|---|
Тема | Re: Improvement of checkpoint IO scheduler for stable transaction responses |
Дата | |
Msg-id | CA+CSw_uQYKi=Njj6+LrVFu7ywyfrWYQy-6eiskjdMhnE1-24hQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improvement of checkpoint IO scheduler for stable transaction responses (Greg Smith <greg@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Wed, Jul 17, 2013 at 1:54 PM, Greg Smith <greg@2ndquadrant.com> wrote: > On 7/16/13 11:36 PM, Ants Aasma wrote: >> >> As you know running a full suite of write benchmarks takes a very long >> time, with results often being inconclusive (noise is greater than >> effect we are trying to measure). > > > I didn't say that. What I said is that over a full suite of write > benchmarks, the effect of changes like this has always averaged out to zero. > You should try it sometime. Then we can have a useful discussion of > non-trivial results instead of you continuing to tell me I don't understand > things. The fact that other changes have been tradeoffs doesn't change the point that there is no tradeoff here. I see no way in which writing blocks to the OS in a logical order is worse than writing them out in arbitrary order. This is why I considered blindly running write benchmarks a waste of time at this point - if the worst case is zero and there are cases where it helps then it can't average out to zero. It would be better to identify the worst case and design a test for that. However I started the full gamut of scale factors and client count tests just do quiet any fears of unexpected regressions. 4 scales, 6 client loads, 3 tests, 20min per test, 2 versions, the results will be done in 48h. Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления: