From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: raised checkpoint limit & manual checkpoint |
Date: | 2016-09-24 13:48:30 |
Message-ID: | alpine.DEB.2.20.1609241534040.6473@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-09-24 14:17:33 | Re: store narrow values in hash indexes? |
Previous Message | Peter Geoghegan | 2016-09-24 13:07:21 | Re: Parallel tuplesort (for parallel B-Tree index creation) |