Re: Support for 8-byte TOAST values, round two

On Mon, Sep 21, 2026 at 03:39:23PM -0700, Bharath Rupireddy wrote:
> On Mon, Sep 21, 2026 at 4:11 AM John Naylor <johncnaylorls(at)gmail(dot)com> 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