Hi,
On Tue, Sep 22, 2026 at 12:58 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> - 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."
Agreed. Using OID/OID8 values and breaking up the sentences reads
better. Please find the attached v2 patch.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
