Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: checkpointer continuous flushing
Date
Msg-id CAA4eK1JY5Y2kTvkr9BWmb+MWed4Gxyb68i3eZPVMX=kca-iu0w@mail.gmail.com
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: checkpointer continuous flushing  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: checkpointer continuous flushing  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Sep 8, 2015 at 8:09 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
>
> Thanks a lot, again, for these tests!
>
> I think that we may conclude, on these run:
>
> (1) sorting seems not to harm performance, and may help a lot.
>

I agree with first part, but about helping a lot, I am not sure based on
the tests conducted by me, among all the runs, it has shown improvement
in average TPS is one case and that too with a dip in number of times the
TPS is below 10.

> (2) Linux flushing with sync_file_range may degrade a little raw tps
>     average in some case, but definitely improves performance stability
>     (always 100% availability when on !).
>

Agreed, I think the benefit is quite clear, but it would be better if we try
to do some more test for the cases (data fits in shared_buffers) where
we saw small regression just to make sure that regression is small.

> (3) posix_fadvise on Linux is a bad idea... the good news is that it
>     is not needed there:-) How good or bad an idea it is on other system
>     is an open question...
>

I don't know what is the best way to verify that, if some body else has
access to such a m/c, please help to get that verified.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Getting total and free disk space from paths in PGDATA
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: function parse_ident