Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
От | Peter Geoghegan |
---|---|
Тема | Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) |
Дата | |
Msg-id | CAEYLb_WBjrhRPuMgnUGHvXdp+VOaRKxbJ0_vYooemMQKx=QjHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Checkpointer split has broken things dramatically (was
Re: DELETE vs TRUNCATE explanation)
|
Список | pgsql-hackers |
On 17 July 2012 23:56, Tom Lane <tgl@sss.pgh.pa.us> wrote: > This implies that nobody has done pull-the-plug testing on either HEAD > or 9.2 since the checkpointer split went in (2011-11-01), because even > a modicum of such testing would surely have shown that we're failing to > fsync a significant fraction of our write traffic. > > Furthermore, I would say that any performance testing done since then, > if it wasn't looking at purely read-only scenarios, isn't worth the > electrons it's written on. In particular, any performance gain that > anybody might have attributed to the checkpointer splitup is very > probably hogwash. > > This is not giving me a warm feeling about our testing practices. The checkpointer slit-up was not justified as a performance optimisation so much as a re-factoring effort that might have some concomitant performance benefits. While I agree that it is regrettable that this was allowed to go undetected for so long, I do not find it especially surprising that some performance testing results post-split didn't strike somebody as fool's gold. Much of the theory surrounding checkpoint tuning, if followed, results in relatively little work being done during the sync phase of a checkpoint, especially if an I/O scheduler like deadline is used. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: