Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
От | Robert Haas |
---|---|
Тема | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? |
Дата | |
Msg-id | CA+TgmoankGsUHuK7UrwdU5j5=3mxDUayDYcrkgO8Myf9cTzkWg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Let PostgreSQL's On Schedule checkpoint write buffer
smooth spread cycle by tuning IsCheckpointOnSchedule?
|
Список | pgsql-hackers |
On Mon, Dec 21, 2015 at 7:51 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > I think that the 1.5 value somewhere in the patch is much too high for the > purpose because it shifts the checkpoint load quite a lot (50% more load at > the end of the checkpoint) just for the purpose of avoiding a spike which > lasts a few seconds (I think) at the beginning. A much smaller value should > be used (1.0 <= factor < 1.1), as it would be much less disruptive and would > probably avoid the issue just the same. I recommend not to commit with a 1.5 > factor in any case. Wait, what? On what workload does the FPW spike last only a few seconds? That's certainly not the case in testing I've done. It would have to be the case that almost all the writes were concentrated on a very few pages. > Another issue I raised is that the load change occurs both with xlog and > time triggered checkpoints, and I'm sure it should be applied in both case. Is this sentence missing a "not"? > Another issue is that the patch makes sense when the WAL & relations are on > the same disk, but might degrade performance otherwise. Yes, that would be a good case to test. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: