Re: Direct TOAST v2, faster, smaller and no migration needed

On Wed, Sep 30, 2026 at 4:56 AM Michael Paquier <michael(at)paquier(dot)xyz> 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