Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgresql.conf.sample

Blame
    • Andres Freund's avatar
      7975c5e0
      Allow the WAL writer to flush WAL at a reduced rate. · 7975c5e0
      Andres Freund authored
      Commit 4de82f7d increased the WAL flush rate, mainly to increase the
      likelihood that hint bits can be set quickly. More quickly set hint bits
      can reduce contention around the clog et al.  But unfortunately the
      increased flush rate can have a significant negative performance impact,
      I have measured up to a factor of ~4.  The reason for this slowdown is
      that if there are independent writes to the underlying devices, for
      example because shared buffers is a lot smaller than the hot data set,
      or because a checkpoint is ongoing, the fdatasync() calls force cache
      flushes to be emitted to the storage.
      
      This is achieved by flushing WAL only if the last flush was longer than
      wal_writer_delay ago, or if more than wal_writer_flush_after (new GUC)
      unflushed blocks are pending. Based on some tests the default for
      wal_writer_delay is 1MB, which seems to work well both on SSD and
      rotational media.
      
      To avoid negative performance impact due to 4de82f7d an earlier
      commit (db76b1ef) made SetHintBits() more likely to succeed; preventing
      performance regressions in the pgbench tests I performed.
      
      Discussion: 20160118163908.GW10941@awork2.anarazel.de
      7975c5e0
      History
      Allow the WAL writer to flush WAL at a reduced rate.
      Andres Freund authored
      Commit 4de82f7d increased the WAL flush rate, mainly to increase the
      likelihood that hint bits can be set quickly. More quickly set hint bits
      can reduce contention around the clog et al.  But unfortunately the
      increased flush rate can have a significant negative performance impact,
      I have measured up to a factor of ~4.  The reason for this slowdown is
      that if there are independent writes to the underlying devices, for
      example because shared buffers is a lot smaller than the hot data set,
      or because a checkpoint is ongoing, the fdatasync() calls force cache
      flushes to be emitted to the storage.
      
      This is achieved by flushing WAL only if the last flush was longer than
      wal_writer_delay ago, or if more than wal_writer_flush_after (new GUC)
      unflushed blocks are pending. Based on some tests the default for
      wal_writer_delay is 1MB, which seems to work well both on SSD and
      rotational media.
      
      To avoid negative performance impact due to 4de82f7d an earlier
      commit (db76b1ef) made SetHintBits() more likely to succeed; preventing
      performance regressions in the pgbench tests I performed.
      
      Discussion: 20160118163908.GW10941@awork2.anarazel.de