From 4bc0f165cb4fbd660648c0153485b3d6f55d80ea Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Fri, 10 Jun 2016 15:31:11 -0700 Subject: Change default of backend_flush_after GUC to 0 (disabled). While beneficial, both for throughput and average/worst case latency, in a significant number of workloads, there are other workloads in which backend_flush_after can cause significant performance regressions in comparison to < 9.6 releases. The regression is most likely when the hot data set is bigger than shared buffers, but significantly smaller than the operating system's page cache. I personally think that the benefit of enabling backend flush control is considerably bigger than the potential downsides, but a fair argument can be made that not regressing is more important than improving performance/latency. As the latter is the consensus, change the default to 0. The other settings introduced in 428b1d6b2 do not have the same potential for regressions, so leave them enabled. Benchmarks leading up to changing the default have been performed by Mithun Cy, Ashutosh Sharma and Robert Haas. Discussion: CAD__OuhPmc6XH=wYRm_+Q657yQE88DakN4=Ybh2oveFasHkoeA@mail.gmail.com --- src/backend/utils/misc/postgresql.conf.sample | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'src/backend/utils/misc/postgresql.conf.sample') diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index 3ef2a9761cc..8260e371bc9 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -170,8 +170,7 @@ #max_parallel_workers_per_gather = 2 # taken from max_worker_processes #old_snapshot_threshold = -1 # 1min-60d; -1 disables; 0 is immediate # (change requires restart) -#backend_flush_after = 0 # 0 disables, - # default is 128kb on linux, 0 otherwise +#backend_flush_after = 0 # 0 disables, default is 0 #------------------------------------------------------------------------------ -- cgit v1.2.3