Re: checkpointer continuous flushing - V18

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checkpointer continuous flushing - V18
Date: 2016-03-10 23:23:56
Message-ID: alpine.DEB.2.10.1603110016270.18837@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


[...]

>> If the default is in pages, maybe you could state it and afterwards
>> translate it in size.
>
> Hm, I think that's more complicated for users than it's worth.

As you wish. I liked the number of pages you used initially because it
really gives a hint of how much random IOs are avoided when they are
contiguous, and I do not have the same just intuition with sizes. Also it
is related to the io queue length manage by the OS.

>> The text could say something about sequential writes performance because
>> pages are sorted.., but that it is lost for large bases and/or short
>> checkpoints ?
>
> I think that's an implementation detail.

As you wish. I thought that understanding the underlying performance model
with sequential writes written in chunks is important for the admin, and
as this guc would have an impact on performance it should be hinted about,
including the limits of its effect where large bases will converge to
random io performance. But maybe that is not the right place.

--
Fabien

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-03-10 23:30:37 Re: checkpointer continuous flushing - V18
Previous Message Tom Lane 2016-03-10 23:17:22 Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.