Re: Support for 8-byte TOAST values, round two

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support for 8-byte TOAST values, round two
Date: 2026-08-13 06:38:58
Message-ID: an1mgtKJxjqN580W@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 10, 2026 at 12:43:37PM +0200, Hannu Krosing wrote:
> The main thing (that I know of) that I have not yet done handling
> VACUUM FULL and CLUSTER for direct toast tables.
>
> Disabling them if direct toast tuples exist is trivial.

Well, you say that. Noted. Now, it also sounds to me that you are
talking about oranges and I am talking about apples, which are two
different things. There is nothing that prevents doing one thing and
the other (I write that after looking at your AI-generated code that
you have mentioned as not reading yourself, yes). Here the apples are
about one full patch set that's posted on this thread, split for
easier review, able to handle all cases we care about in core
including backward-compatibility, relation rewrites, upgrades,
dump/restore, versus oranges clearly presented as partially complete
without a clear complete picture.

Honestly, and to keep it short, I don't see enough arguments to be
convinced that the oranges are better than the apples. Having the
code presenting the oranges to be fully generated by an LLM agent
does not help IMO, either.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-13 06:57:39 Re: Fix a host of strto*() bugs
Previous Message Michael Paquier 2026-08-13 06:28:23 Re: problems with toast.* reloptions