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

On Wed, Sep 30, 2026 at 12:44:28PM +0200, Hannu Krosing wrote:
> In my insert tests 8-byte TOAST was much faster that 4-byte toast
>
> This resulted in a solid 23% speed-up because it didn't need to verify
> new OIDs against the unique index, despite each toast index entry
> taking up slightly more space (30.1 bytes vs. 21.4 bytes on average)

The speedup is not surprising. Thanks for posting some numbers.

A note about that. Postgres hackers had a meetup two weeks ago in
Tokyo where I have reported the activity of this thread, including the
fact that the new values are not rechecked in the INSERT path.

My opinion, same as upthread, is that a recheck is kind of pointless
because we should never go backwards under normal running conditions
and we would run out of LSNs before we reach the OID8 limit. I did
mention the argument of using pg_resetwal -o to go backwards, leading
to INSERT failures due to duplicates of the TOAST unique index.
Fujii-san had a more biased opinion than mine, mentioning that a
recheck could be a more defensive position, even if it costs in normal
running conditions.

Perhaps my opinion will be overruled in this release cycle, which is
fine, I just want to point out that the API toastid_valueid_exists()
is transparently able to work with a recheck of Oid8 values, so the
value recheck could be plugged in for this case as well, depending on
how the discussion flows. Perhaps there is a bug I am not aware of
yet, that could justify the recheck, of course.
--
Michael