toastlimit.patch

application/octet-stream

Filename: toastlimit.patch
Type: application/octet-stream
Part: 0
Message: Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

Patch

Same data as JSON: GET /api/v1/attachments/:id/patch the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes. API reference →
Format: unified
File+
doc/src/sgml/limits.sgml 10 0
diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml
index c549447013..1571761f15 100644
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -135,4 +135,14 @@
   created tuples are internally marked as null in the tuple's null bitmap, the
   null bitmap also occupies space.
  </para>
+
+ <para>
+  Each table can store a theoretical maximum of 2^32 out-of-line values; see
+  <xref linkend="storage-toast" /> for a detailed discussion of out-of-line
+  storage. This limit arises from the use of a 32-bit OID to identify each
+  such value. The practical limit is significantly less than the theoretical
+  limit, because as the OID space fills up, finding an OID that is still free
+  can become expensive. Typically, this is only an issue for tables containing
+  many terabytes of data; partitioning is a possible workaround.
+ </para>
 </appendix>