The attached patch addresses one of the open non-blockers for beta3. These are tuning points which emerged in testing. The first is more likely to be helpful. The second may be very important in a few types of transaction mixes, but I threw in a lot of weasel words and qualifiers because someone could easily try this to bring down the transaction retry rate, but suffer a net loss in throughput because less efficient plans could be chosen. I hope I made that point in a reasonable fashion, although I'm certainly open to suggestions for better wording. -Kevin
*** a/doc/src/sgml/mvcc.sgml --- b/doc/src/sgml/mvcc.sgml *************** *** 658,663 **** ERROR: could not serialize access due to read/write dependencies among transact --- 658,680 ---- protections automatically provided by Serializable transactions. </para> </listitem> + <listitem> + <para> + If you are seeing a lot of serialization failures because multiple + page locks are being combined into relation locks, you might want to + increase <xref linkend="guc-max-pred-locks-per-transaction">. + </para> + </listitem> + <listitem> + <para> + If you are experiencing a lot of serialization failures due to + table-scan plans being used, you might want to try 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>
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers