On Fri, May 27, 2016 at 12:37 AM, Andres Freund <and...@anarazel.de> wrote: > I don't think the situation is quite that simple. By *disabling* backend > flushing it's also easy to see massive performance regressions. In > situations where shared buffers was configured appropriately for the workload > (not the case here IIRC).
On what kind of workload does setting backend_flush_after=0 represent a large regression vs. the default settings? I think we have to consider that pgbench and parallel copy are pretty common things to want to do, and a non-zero default setting hurts those workloads a LOT. I have a really hard time believing that the benefits on other workloads are large enough to compensate for the slowdowns we're seeing here. We have nobody writing in to say that backend_flush_after>0 is making things way better for them, and Ashutosh and I have independently hit massive slowdowns on unrelated workloads. We weren't looking for slowdowns in this patch. We were trying to measure other stuff, and ended up tracing the behavior back to this patch. That really, really suggests that other people will have similar experiences. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers