Re: Perf Benchmarking and regression. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Perf Benchmarking and regression.
Date
Msg-id 20160603060922.l4pw3swckinen7il@alap3.anarazel.de
Whole thread Raw
In response to Re: Perf Benchmarking and regression.  (Noah Misch <noah@leadboat.com>)
Responses Re: Perf Benchmarking and regression.  (Noah Misch <noah@leadboat.com>)
Re: Perf Benchmarking and regression.  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Perf Benchmarking and regression.
Next
From: Michael Paquier
Date:
Subject: Re: [BUGS] BUG #14155: bloom index error with unlogged table