On Fri, May 27, 2016 at 12:37 AM, Andres Freund <andres@anarazel.de> wrote:
> I don't think the situation is quite that simple. By *disabling* backend flushing it's also easy to see massive
performanceregressions. In situations where shared buffers was configured appropriately for the workload (not the case
hereIIRC).
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
