From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de> |
Subject: | raised checkpoint limit & manual checkpoint |
Date: | 2016-09-24 06:42:16 |
Message-ID: | alpine.DEB.2.20.1609240818210.6473@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
The checkpoint time limit has just been raised to one day after a
discussion started by Andres Freund:
https://www.postgresql.org/message-id/20160202001320.GP8743%40awork2.anarazel.de
I would have gone further up, say one week or even one month, but I think
that this new limit is an improvement over the previous 1 hour maximum.
Now ISTM that there is a possible use case which arises with this new
setting and is not well addressed by postgresql:
Let us say that an application has periods of high and low usage, say over
a day, so that I want to avoid a checkpoint from 8 to 20, but I'm okay
after that. I could raise the size and time limits so that they do not
occur during these hours and plan to do a manual CHECKPOINT once a day
when I see fit.
Now the problem I see is that CHECKPOINT means "do a CHECKPOINT right now
as fast as possible", i.e. there is no throttling whatsoever, which leads
to heavy IO and may result in a very unresponsive database.
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.
Any thoughts?
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-09-24 07:58:28 | Re: 9.6 TAP tests and extensions |
Previous Message | Pavel Stehule | 2016-09-24 06:01:33 | Re: patch: function xmltable |