On Thu, Jul 30, 2026 at 9:53 AM Nikita Malakhov <[email protected]> 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
