Hi All,

As we have seen the regression of more than 45% with "*backend_flush_after*"
enabled and set to its default value i.e. 128KB or even when it is set to
some higher value like 2MB, i think we should disable it such that it does
not impact the read write performance and here is the attached patch for
the same.  Please have a look and let me know your thoughts on this. Thanks!

With Regards,
Ashutosh Sharma
EnterpriseDB: http://www.enterprisedb.com

On Sun, May 15, 2016 at 1:26 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:

>
> These raw tps suggest that {backend,bgwriter}_flush_after should better be
>>> zero for this kind of load.Whether it should be the default is unclear
>>> yet,
>>> because as Andres pointed out this is one kind of load.
>>>
>>
>> FWIW, I don't think {backend,bgwriter} are the same here. It's primarily
>> backend that matters.
>>
>
> Indeed, I was a little hasty to put bgwriter together based on this report.
>
> I'm a little wary of "bgwriter_flush_after" though, I would not be
> surprised if someone reports some regressions, although probably not with a
> pgbench tpcb kind of load.
>
> --
> Fabien.
>
diff --git a/src/include/storage/bufmgr.h b/src/include/storage/bufmgr.h
index 38b6027..fff7104 100644
--- a/src/include/storage/bufmgr.h
+++ b/src/include/storage/bufmgr.h
@@ -60,7 +60,7 @@ extern PGDLLIMPORT int NBuffers;
 /* FIXME: Also default to on for mmap && msync(MS_ASYNC)? */
 #ifdef HAVE_SYNC_FILE_RANGE
 #define DEFAULT_CHECKPOINT_FLUSH_AFTER 32
-#define DEFAULT_BACKEND_FLUSH_AFTER 16
+#define DEFAULT_BACKEND_FLUSH_AFTER 0
 #define DEFAULT_BGWRITER_FLUSH_AFTER 64
 #else
 #define DEFAULT_CHECKPOINT_FLUSH_AFTER 0
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to