Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
Date: 2016-01-17 08:06:04
Message-ID: alpine.DEB.2.10.1601170855260.18181@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Coming in late here, but I always thought the fact that the FPW happen
> mostly at the start of the checkpoint, and the checkpoint writes/fsyncs
> happen mostly in the first half of the checkpoint period was always
> suboptimal, i.e. it would be nice of one of these was more active in the
> second half of the checkpoint period. I assume that is what is being
> discussed here.

Yes, this is the subject of the thread.

On the one end hand, whether is the first half or first quarter of first
tenth really depends on the actual load, so how much to rebalance depends
on that dynamic information. At the beginning there should be a short
spike for index pages which are quickly reused, and a longer spike about
data pages depending on the pattern of access and size of table.

On the other hand the rebalancing also depends on the measure chosen to
know about the overall progress, either WAL writing or time, and their
behavior is not the same, so this should be taken into account.

My conclusion is that there is no simple static fix to this issue, as
proposed in the submitted patch. The problem needs thinking and maths.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Seltenreich 2016-01-17 11:38:26 [PATCH] Improve spinlock inline assembly for x86.
Previous Message Pavel Stehule 2016-01-17 07:43:56 Re: count_nulls(VARIADIC "any")