On Wed, Sep 30, 2026 at 4:56 AM Michael Paquier <[email protected]> wrote: > > Yes, we've relied on the concept of TOAST tuple "identity" heavily for > 20-ish years.
I will investigate an option to include more resiliency data, including chunk numbers, in the larger TOAST chunks. They probably would be redundant in single-chunk toast I will also investigate adding a back-pointer to the original tuple, which can be handy in some repacking scenarios. > You could introduce a new behavior based on tids as an opt-in, I > guess, leaving the default 4-bytes be, giving access to tid-based > access tables for newly-created TOAST tables. It was already optional and dynamic ALTER TABLE ... WITH (toast_flavour=direct) It is already implemented for both 4- and 8-byte-oid toast The latest discussion made me realise that I should also keep the table structure as the classic/plain toast with just three fields unless direct toast is requested so that the VACUUMing properties stay the same . The extra fields will only be added when you set the direct toast option, after that, direct vacuuming of toast will be disabled. -- Hannu
