On 2016-06-03 10:48:18 -0400, Noah Misch wrote: > On Thu, Jun 02, 2016 at 11:09:22PM -0700, Andres Freund wrote: > > > 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.
Meh. That's not actually all that often the case. This unstable performance issue, with the minute-long stalls, is the worst and most frequent production problem people hit with postgres in my experience, besides issues with autovacuum. Ignoring that is just hurting our users. > > 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. Have you actually looked at the thread with all the numbers? This isn't an issue that has been decided willy-nilly. It's been discussed *over months*. 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
