Re: Redesigning checkpoint_segments

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Redesigning checkpoint_segments
Дата
Msg-id 51B0EC83.60700@vmware.com
обсуждение исходный текст
Ответ на Re: Redesigning checkpoint_segments  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Redesigning checkpoint_segments  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 06.06.2013 20:24, Josh Berkus wrote:
>> Yeah, something like that :-). I was thinking of letting the estimate
>> decrease like a moving average, but react to any increases immediately.
>> Same thing we do in bgwriter to track buffer allocations:
>
> Seems reasonable.

Here's a patch implementing that. Docs not updated yet. I did not change
the way checkpoint_segments triggers checkpoints - that'll can be a
separate patch. This only decouples the segment preallocation behavior
from checkpoint_segments. With the patch, you can set
checkpoint_segments really high, without consuming that much disk space
all the time.

> Given the behavior of xlog, I'd want to adjust the
> algo so that peak usage on a 24-hour basis would affect current
> preallocation.  That is, if a site regularly has a peak from 2-3pm where
> they're using 180 segments/cycle, then they should still be somewhat
> higher at 2am than a database which doesn't have that peak.  I'm pretty
> sure that the bgwriter's moving average cycles much shorter time scales
> than that.

Makes sense. I didn't implement that in the attached, though.

Having a separate option to specify a minimum number of segments (or
rather minimum size in MB) to keep preallocated would at least allow a
DBA to set that manually, based on the observed peak. I didn't implement
such a manual option in the attached, but that would be easy.

- Heikki

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Cost limited statements RFC
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Vacuum, Freeze and Analyze: the big picture