On Mon, Sep 21, 2026 at 03:39:23PM -0700, Bharath Rupireddy wrote: > On Mon, Sep 21, 2026 at 4:11 AM John Naylor <[email protected]> wrote: >> It looks like doc/src/sgml/limits.sgml needs to be updated as well. > > Nice catch. Thanks for pointing it out. Please find the attached patch for > that.
- 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. + values are large enough to require it. Only an 18-byte or 22-byte pointer + must remain inside the tuple in the table's heap, for a TOAST table using an + OID or an OID8 respectively. 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. How about the following instead for this part, slightly tweaked: "Only an 18-byte or 22-byte TOAST pointer must remain inside the tuple in the table's heap, depending on whether the TOAST table uses OID or OID8 values, respectively. 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." Typically, this is only an issue for tables containing many terabytes of data; partitioning is a possible workaround. + A TOAST table using an OID8 does not have this issue, as it can store up + to 2^64 out-of-line values and new identifiers are assigned without + searching for a free one; see <xref linkend="reloption-toast-value-type"/>. And here, a bit cleaned up: "A TOAST table using OID8 values does not have this issue as it can store up to 2^64 out-of-line values. New identifiers are assigned without searching for a free one. See <xref linkend="reloption-toast-value-type"/> for details." -- Michael
signature.asc
Description: PGP signature
