Re: Direct Toast PoC

On Thu, Jul 30, 2026 at 9:53 AM Nikita Malakhov <hukutoc(at)gmail(dot)com> wrote:
>
> Hi!
>
> I keep thinking about this. Hannu, have you thought about a mixed
approach?
> In [1] above Michael mentioned the very serious drawback of using direct
TIDs -
> while vacuuming the TOAST table we have to modify the original table as
well,
> so I don't see a way to avoid using some kind of index at all.

My main motivation is getting rid of the index, as the individual
index lookups are the main source of query slowdowns.

And increasing the toast OID size to solve running out of OIDs will
only worsen the performance issue as it makes the toast index
larger. And it makes the issue worse in exactly the case it tries to
solve, as the index lookup slowdown worsens with larger indexes.

In case of VACUUM FULL / CLUSTER you very much *want to re-order*
the toasted fields to be *in the main table order* not in oid order
if you do any sequential scans, or even spot look-ups for rows with
multiple toasted fields.

So the solution is to disallow VACUUM FULL directed to the toast
table and to modify the VACUUM FULL / CLUSTER to have an option to
also cluster the toast table while working on the main table.

> My direct TOAST patch was just a PoC to show it is possible.

I'll take a serious look at your patch when moving forward to implement
something aimed to actually go into the core.

It could be easier to start from that than cleaning up the current AI code
:)

---
Hannu