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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
