From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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-06-03 06:09:22 |
Message-ID: | 20160603060922.l4pw3swckinen7il@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-06-03 01:57:33 -0400, Noah Misch wrote:
> > Which means that transactional workloads that are bigger than the OS
> > memory, or which have a non-uniform distribution leading to some
> > locality, are likely to be faster. In practice those are *hugely* more
> > likely than the uniform distribution that pgbench has.
>
> That is formally true; non-benchmark workloads rarely issue uniform writes.
> However, enough non-benchmark workloads have too little locality to benefit
> from caches. Those will struggle against *_flush_after like uniform writes
> do, so discounting uniform writes wouldn't simplify this project.
But such workloads rarely will hit the point of constantly re-dirtying
already dirty pages in kernel memory within 30s.
> Today's defaults for *_flush_after greatly smooth and accelerate performance
> for one class of plausible workloads while greatly slowing a different class
> of plausible workloads.
I don't think checkpoint_flush_after is in that class, due to the
fsync()s we already emit at the end of checkpoints.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-03 06:11:59 | Re: [BUGS] BUG #14155: bloom index error with unlogged table |
Previous Message | Noah Misch | 2016-06-03 05:57:33 | Re: Perf Benchmarking and regression. |