1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
<!-- doc/src/sgml/limits.sgml -->
<appendix id="limits">
<title><productname>PostgreSQL</productname> Limits</title>
<para>
<xref linkend="limits-table"/> describes various hard limits of
<productname>PostgreSQL</productname>. However, practical limits, such as
performance limitations or available disk space may apply before absolute
hard limits are reached.
</para>
<table id="limits-table">
<title><productname>PostgreSQL</productname> Limitations</title>
<tgroup cols="3">
<thead>
<row>
<entry>Item</entry>
<entry>Upper Limit</entry>
<entry>Comment</entry>
</row>
</thead>
<tbody>
<row>
<entry>database size</entry>
<entry>unlimited</entry>
<entry></entry>
</row>
<row>
<entry>number of databases</entry>
<!-- 2^32 - FirstNormalObjectId - 1 -->
<entry>4,294,950,911</entry>
<entry></entry>
</row>
<row>
<entry>relations per database</entry>
<!-- (2^32 - FirstNormalObjectId - 1) / 3 (3 because of the table and the
two types that are created to go with it) -->
<entry>1,431,650,303</entry>
<entry></entry>
</row>
<row>
<entry>relation size</entry>
<entry>32 TB</entry>
<entry>with the default <symbol>BLCKSZ</symbol> of 8192 bytes</entry>
</row>
<row>
<entry>rows per table</entry>
<entry>limited by the number of tuples that can fit onto 4,294,967,295 pages</entry>
<entry></entry>
</row>
<row>
<entry>columns per table</entry>
<entry>1,600</entry>
<entry>further limited by tuple size fitting on a single page; see note
below</entry>
</row>
<row>
<entry>columns in a result set</entry>
<entry>1,664</entry>
<entry></entry>
</row>
<row>
<entry>field size</entry>
<entry>1 GB</entry>
<entry></entry>
</row>
<row>
<entry>indexes per table</entry>
<entry>unlimited</entry>
<entry>constrained by maximum relations per database</entry>
</row>
<row>
<entry>columns per index</entry>
<entry>32</entry>
<entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
</row>
<row>
<entry>partition keys</entry>
<entry>32</entry>
<entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
</row>
<row>
<entry>identifier length</entry>
<entry>63 bytes</entry>
<entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
</row>
<row>
<entry>function arguments</entry>
<entry>100</entry>
<entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
</row>
<row>
<entry>query parameters</entry>
<entry>65,535</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>
The maximum number of columns for a table is further reduced as the tuple
being stored must fit in a single 8192-byte heap page. For example,
excluding the tuple header, a tuple made up of 1,600 <type>int</type> columns
would consume 6400 bytes and could be stored in a heap page, but a tuple of
1,600 <type>bigint</type> columns would consume 12800 bytes and would
therefore not fit inside a heap page.
Variable-length fields of
types such as <type>text</type>, <type>varchar</type>, and <type>char</type>
can have their values stored out of line in the table's TOAST table when the
values are large enough to require it. Only an 18-byte pointer must remain
inside the tuple in the table's heap. For shorter length variable-length
fields, either a 4-byte or 1-byte field header is used and the value is
stored inside the heap tuple.
</para>
<para>
Columns that have been dropped from the table also contribute to the maximum
column limit. Moreover, although the dropped column values for newly
created tuples are internally marked as null in the tuple's null bitmap, the
null bitmap also occupies space.
</para>
</appendix>
|
