Commit4d93bbd

committed

Document limit on the number of out-of-line values per table

Document the hard limit stemming from the size of an OID, and alsomention the perfomance impact that occurs before the hard limitis reached.Jakub Wartak and Robert HaasBackpatch to all supported versionsDiscussion:https://postgr.es/m/CAKZiRmwWhp2yxjqJLwbBjHdfbJBcUmmKMNAZyBjjtpgM9AMatQ%40mail.gmail.com

1 parent9758174 commit4d93bbdCopy full SHA for 4d93bbd

File tree

+11

-0

lines changed

+11

-0

lines changed

Lines changed: 11 additions & 0 deletions

Original file line number	Diff line number	Diff line change
`@@ -135,4 +135,15 @@`
`135`	`135`	`created tuples are internally marked as null in the tuple's null bitmap, the`
`136`	`136`	`null bitmap also occupies space.`
`137`	`137`	`</para>`
	`138`	`+`
	`139`	`+ <para>`
	`140`	`+ Each table can store a theoretical maximum of 2^32 out-of-line values; see`
	`141`	`+ <xref linkend="storage-toast" /> for a detailed discussion of out-of-line`
	`142`	`+ storage. This limit arises from the use of a 32-bit OID to identify each`
	`143`	`+ such value. The practical limit is significantly less than the theoretical`
	`144`	`+ limit, because as the OID space fills up, finding an OID that is still free`
	`145`	`+ can become expensive, in turn slowing down INSERT/UPDATE statements.`
	`146`	`+ Typically, this is only an issue for tables containing many terabytes`
	`147`	`+ of data; partitioning is a possible workaround.`
	`148`	`+ </para>`
`138`	`149`	`</appendix>`

Comments

(0)