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.
