Re: checkpointer continuous flushing

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checkpointer continuous flushing
Date: 2015-08-18 07:08:43
Message-ID: alpine.DEB.2.10.1508180828270.11520@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Amit,

>> So the option is best kept as "off" for now, without further data, I'm
>> fine with that.
>
> One point to think here is on what basis user can decide make
> this option on, is it predictable in any way?
> I think one case could be when the data set fits in shared_buffers.

Yep.

> In general, providing an option is a good idea if user can decide with
> ease when to use that option or we can give some clear recommendation
> for the same otherwise one has to recommend that test your workload with
> this option and if it works then great else don't use it which might
> also be okay in some cases, but it is better to be clear.

My opinion, which is not backed by any data (anyone can feel free to
provide a FreeBSD box for testing...) is that it would mostly be an
improvement if you have a significant write load to have the flush option
on when running on non-Linux systems which provide posix_fadvise.

If you have a lot of reads and few writes, then postgresql currently works
reasonably enough, which is why people do not complain too much about
write stalls, and I expect that the situation would not be significantly
degraded.

Now there are competing positive and negative effects induced by using
posix_fadvise, and moreover its implementation varries from OS to OS, so
without running some experiments it is hard to be definite.

> One minor point, while glancing through the patch, I noticed that couple
> of multiline comments are not written in the way which is usually used
> in code (Keep the first line as empty).

Indeed.

Please find attached a v10, where I have reviewed comments for style &
contents, and also slightly extended the documentation about the flush
option to hint that it is essentially useful for high write loads. Without
further data, I think it is not obvious to give more definite advices.

--
Fabien.

Attachment Content-Type Size
checkpoint-continuous-flush-10-a.patch text/x-diff 20.0 KB
checkpoint-continuous-flush-10-b.patch text/x-diff 28.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2015-08-18 08:20:03 Re: jsonb array-style subscripting
Previous Message Noah Misch 2015-08-18 05:59:30 Re: Raising our compiler requirements for 9.6