On Thu, Jun 02, 2016 at 11:09:22PM -0700, Andres Freund wrote: > 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.
Rarely, yes. Not rarely enough to discount. > > 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. The usual PostgreSQL handling of a deeply workload-dependent performance feature is to disable it by default. That's what I'm inclined to do here, for every GUC the feature added. Sophisticated users will nonetheless fully exploit this valuable mechanism in 9.6. > I don't think checkpoint_flush_after is in that class, due to the > fsync()s we already emit at the end of checkpoints. That's a promising hypothesis. Some future project could impose a nonzero default checkpoint_flush_after, having demonstrated that it imposes negligible harm in the plausible cases it does not help. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
