| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: Perf Benchmarking and regression. |
| Date: | 2016-05-14 17:04:47 |
| Message-ID: | 20160514170447.zzfl2chxllbdwuss@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-05-14 18:49:27 +0200, Fabien COELHO wrote:
>
> Hello,
>
> > Please find the results for the following 3 scenarios with unpatched master:
> >
> > 1. Default settings for *_flush_after : TPS = *10677.662356*
> > 2. backend_flush_after=0, rest defaults : TPS = *18452.655936*
> > 3. backend_flush_after=0, bgwriter_flush_after=0,
> > wal_writer_flush_after=0, checkpoint_flush_after=0 : TPS = *18614.479962*
>
> Thanks for these runs.
Yes!
> These raw tps suggest that {backend,bgwriter}_flush_after should better be
> zero for this kind of load.Whether it should be the default is unclear yet,
> because as Andres pointed out this is one kind of load.
FWIW, I don't think {backend,bgwriter} are the same here. It's primarily
backend that matters. This is treating the os page cache as an
extension of postgres' buffer cache. That really primarily matters for
backend_, because otherwise backends spend time waiting for IO.
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-05-14 17:51:31 | exit() behavior on Windows? |
| Previous Message | Fabien COELHO | 2016-05-14 16:49:27 | Re: Perf Benchmarking and regression. |