Commit771a9f6

committed

Performance tuning advice for SSI.

Kevin Grittner, with additional wordsmithing by me.

1 parenta3290f6 commit771a9f6Copy full SHA for 771a9f6

File tree

+20

-0

lines changed

+20

-0

lines changed

Lines changed: 20 additions & 0 deletions

Original file line number	Diff line number	Diff line change
`@@ -658,6 +658,26 @@ ERROR: could not serialize access due to read/write dependencies among transact`
`658`	`658`	`protections automatically provided by Serializable transactions.`
`659`	`659`	`</para>`
`660`	`660`	`</listitem>`
	`661`	`+ <listitem>`
	`662`	`+ <para>`
	`663`	`+ When the system is forced to combine multiple page-level predicate`
	`664`	`+ locks into a single relation-level predicate lock because the predicate`
	`665`	`+ lock table is short of memory, an increase in the rate of serialization`
	`666`	`+ failures may occur. You can avoid this by increasing`
	`667`	`+ <xref linkend="guc-max-pred-locks-per-transaction">.`
	`668`	`+ </para>`
	`669`	`+ </listitem>`
	`670`	`+ <listitem>`
	`671`	`+ <para>`
	`672`	`+ A sequential scan will always necessitate a relation-level predicate`
	`673`	`+ lock. This can result in an increased rate of serialization failures.`
	`674`	`+ It may be helpful to encourage the use of index scans by reducing`
	`675`	`+ <xref linkend="guc-random-page-cost"> and/or increasing`
	`676`	`+ <xref linkend="guc-cpu-tuple-cost">. Be sure to weigh any decrease`
	`677`	`+ in transaction rollbacks and restarts against any overall change in`
	`678`	`+ query execution time.`
	`679`	`+ </para>`
	`680`	`+ </listitem>`
`661`	`681`	`</itemizedlist>`
`662`	`682`	`</para>`
`663`	`683`

Comments

(0)