From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 22 Jun 2011 01:54:36 +0000 (-0400)
Subject: Performance tuning advice for SSI.
X-Git-Tag: REL9_2_BETA1~1522
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=771a9f69f70e0b4fa95347df7ab346e5bdbc85f2;p=postgresql

Performance tuning advice for SSI.

Kevin Grittner, with additional wordsmithing by me.
---

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index e688176acb..1d337b8055 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -658,6 +658,26 @@ ERROR:  could not serialize access due to read/write dependencies among transact
        protections automatically provided by Serializable transactions.
       </para>
      </listitem>
+     <listitem>
+      <para>
+       When the system is forced to combine multiple page-level predicate
+       locks into a single relation-level predicate lock because the predicate
+       lock table is short of memory, an increase in the rate of serialization
+       failures may occur.  You can avoid this by increasing
+       <xref linkend="guc-max-pred-locks-per-transaction">.
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       A sequential scan will always necessitate a relation-level predicate
+       lock.  This can result in an increased rate of serialization failures.
+       It may be helpful to encourage the use of index scans by reducing
+       <xref linkend="guc-random-page-cost"> and/or increasing
+       <xref linkend="guc-cpu-tuple-cost">.  Be sure to weigh any decrease
+       in transaction rollbacks and restarts against any overall change in
+       query execution time.
+      </para>
+     </listitem>
     </itemizedlist>
    </para>