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-09-09 09:01:35 |
Message-ID: | alpine.DEB.2.10.1509091042290.3177@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Amit,
>> 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
I'm focussing on the "sort" dimension alone, that is I'm comparing the
average tps performance with sorting with the same test without sorting, :
There are 4 cases from your tests, if I'm not mistaken:
- T1 flush=off 27480 -> 27482 : +0.0%
- T1 flush=on 25214 -> 26819 : +6.3%
- T2 flush=off 5050 -> 6194 : +22.6%
- T2 flush=on 2771 -> 6110 : +120.4%
The average improvement induced by sort=on is +50%, if you do not agree on
"a lot", maybe we can agree on "significantly":-)
> 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.
I've already reported a lot of tests (several hundred of hours on two
different hosts), and I did not have such a dip, but the hardware was more
"usual" or "casual", really different from your runs.
If you can run more tests, great!
I think that the main safeguard to handle the (small) uncertainty is to
keep gucs to control these features.
>> (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.
Yep. There has been such calls on this thread which were not very
effective, up to now.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2015-09-09 09:54:44 | Re: On-demand running query plans using auto_explain and signals |
Previous Message | Pavel Stehule | 2015-09-09 08:46:52 | Re: On-demand running query plans using auto_explain and signals |