postgres.git / summary / log / commit / refs

commit    66370f5158f2bca02202376204bfccdfdafd2bd4
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Wed Jun 22 01:54:36 2011 +0000
First released in: 9.2.0, 9.1.0

    Performance tuning advice for SSI.
    
    Kevin Grittner, with additional wordsmithing by me.


 doc/src/sgml/mvcc.sgml | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index e688176acb4..1d337b80550 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>
 


[parent: 0272fd1c008a]