Re: raised checkpoint limit & manual checkpoint

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

In response to

Browse pgsql-hackers by date

  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)