Re: raised checkpoint limit & manual checkpoint - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: raised checkpoint limit & manual checkpoint
Date
Msg-id alpine.DEB.2.20.1609241534040.6473@lancre
Whole thread Raw
In response to Re: raised checkpoint limit & manual checkpoint  (Amit Kapila <amit.kapila16@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Bruce Momjian
Date:
Subject: Re: store narrow values in hash indexes?