Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
От | Fabien COELHO |
---|---|
Тема | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? |
Дата | |
Msg-id | alpine.DEB.2.10.1507051441220.26569@sto обсуждение исходный текст |
Ответ на | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? (Heikki Linnakangas <hlinnaka@iki.fi>) |
Список | pgsql-hackers |
> You don't have to do anything if you don't want to. Sure:-) What I mean is that I think that this patch is not ripe, and I understood that some people were suggesting that it could be applied as is right away. I'm really disagreeing with that. > I said myself that this needs performance testing of the worst-case > scenario, one where we would expect this to perform worse than without > the patch. Then we can look at how bad that effect is, and decide if > that's acceptable. Ok, I'm fine with that. It's quite different from "looks ok apply now". > That said, if you could do that testing, that would be great! Hmmm. I was not really planing to. On the other hand, I have some scripts and a small setup that I've been using to test checkpointer flushing, and it would be easy to start some tests. >> 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. > > Yeah, a GUC would be helpful in testing this. I'm hoping that we would come > up with a reasonable formula that would work well enough for everyone that we > wouldn't need to have a GUC in the final patch, though. Yep. If it is a guc testing is quite easy and I may run my scripts... -- Fabien.
В списке pgsql-hackers по дате отправления: