From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
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-09-09 03:31:44 |
Message-ID: | CAA4eK1JY5Y2kTvkr9BWmb+MWed4Gxyb68i3eZPVMX=kca-iu0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 8, 2015 at 8:09 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-09-09 03:33:00 | Re: proposal: function parse_ident |
Previous Message | Michael Paquier | 2015-09-09 03:17:38 | Re: Getting total and free disk space from paths in PGDATA |