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
signature.asc
Description: PGP signature
