Re: Improvement of checkpoint IO scheduler for stable transaction responses

On 7/18/13 12:00 PM, Alvaro Herrera wrote:
> I think the idea is to have a system in which most of the time the
> recovery time will be that for checkpoint_timeout=5, but in those
> (hopefully rare) cases where checkpoints take a bit longer, the recovery
> time will be that for checkpoint_timeout=6.

I understand the implementation. My point is that if you do that, the
fair comparison is to benchmark it against a current system where
checkpoint_timeout=6 minutes. That is a) simpler, b) requires no code
change, and c) makes the looser standards the server is now settling for
transparent to the administrator. Also, my expectation is that it would
perform better all of the time, not just during the periods this new
behavior kicks in.

Right now we have checkpoint_completion_target as a GUC for controlling
what's called the spread of a checkpoint over time. That sometimes goes
over, but that's happening against the best attempts of the server to do
better.

The first word that comes to mind for for just disregarding the end time
is that it's a sloppy checkpoint. There is all sorts of sloppy behavior
you might do here, but I've worked under the assumption that ignoring
the contract with the administrator was frowned on by this project. If
people want this sort of behavior in the server, I'm satisfied my
distaste for the idea and the reasoning behind it is clear now.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com