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