Re: Perf Benchmarking and regression.

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Perf Benchmarking and regression.
Дата
Msg-id 20160603060922.l4pw3swckinen7il@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Perf Benchmarking and regression.  (Noah Misch <noah@leadboat.com>)
Ответы Re: Perf Benchmarking and regression.
Re: Perf Benchmarking and regression.
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Perf Benchmarking and regression.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [BUGS] BUG #14155: bloom index error with unlogged table