aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2016-06-10 15:31:11 -0700
committerAndres Freund <andres@anarazel.de>2016-06-10 15:31:11 -0700
commit4bc0f165cb4fbd660648c0153485b3d6f55d80ea (patch)
treefde5dfaf4d50a935d67ce57e0eb299601ff104ed /contrib/postgres_fdw/postgres_fdw.c
parent3303ea1a327b41d3b406d7be7a5ce2901e561066 (diff)
downloadpostgresql-4bc0f165cb4fbd660648c0153485b3d6f55d80ea.tar.gz
postgresql-4bc0f165cb4fbd660648c0153485b3d6f55d80ea.zip
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
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions