I would suggest that a good complementary feature would be to allow a manual
checkpoint to run over a period of time, say something like:
CHECKPOINT OVER '10 hours';
That would target to complete after this period (whether it succeeds or not
is another issue) instead of going as fast as possible, thus avoiding
some performance degradation.
Isn't it somewhat overlaps with existing parameter
checkpoint_completion_target?
More or less. The difference is that throttled checkpoints are currently
started *automatically* when an certain amount of work has been done or
some time as passed, but you cannot start them manually.
You can use checkpoint_completion_target to throttle the checkpoints.
Nearly yes, however it does not give any control to when a throttle
checkpoint is started. I'm arguing that since the configuration allows to
delay checkpointing up to a day, than the ability to control when to
actually start one seems to make sense.
The option you are suggesting seems to be more straight forward, but how
will user decide the time he wants Checkpoint to take.
In the hypothetical use case I have in mind, the user would happen to know
its load well enough to choose. Say the system supports a load linked to
office hour, you would know that you want it done before the next
morning.
--
Fabien
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
