Horton

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

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Nikita Malakhov <hukutoc@gmail.com>
Cc: Hannu Krosing <hannuk@google.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Nikhil Kumar Veldanda <veldanda.nikhilkumar17@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>
Date: 2025-07-21T22:43:05Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add data type oid8, 64-bit unsigned identifier

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