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
signature.asc
Description: PGP signature
