Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nikita Malakhov <hukutoc(at)gmail(dot)com>
Cc: Hannu Krosing <hannuk(at)google(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikhil Kumar Veldanda <veldanda(dot)nikhilkumar17(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)
Date: 2025-07-21 22:43:05
Message-ID: aH7CeVnZLaJtJ85S@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 21, 2025 at 02:20:31PM +0300, Nikita Malakhov wrote:
> I agree that storing reltoastrelid in each Toast pointer seems to be
> a waste of disk space since the current Postgres state does not
> allow multiple TOAST tables per relation.

va_toastrelid is a central part of the current system when dealing
with a TOAST relation rewrite, because we need to know to which
relation an on-disk TOAST pointer is part of. Or do you mean that we
don't need that with what you are proposing with TIDs? Perhaps yes,
sure, I've not studied this question when associated with your patch
(which has a bunch of duplicated code that could be avoided AFAIK).

> But if we consider this as a viable option it could bring additional
> advantages. I've successfully tried to use multiple TOAST tables,
> with different variations - by type, by column and as-is just as
> an extensible storage.

I don't think we need to be that ambitious. There is no way to say
such things could have any benefits in the long-term and there's the
catalog representation part. Even if we do that, I suspect that users
would never really know which setup makes sense because we would want
to control how things happen at a relation level and not purely
automate a behavior.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-07-21 22:54:37 Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)
Previous Message Jacob Champion 2025-07-21 22:20:28 Re: [PATCH] Check for TupleTableSlot nullness before dereferencing