| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | John Naylor <johncnaylorls(at)gmail(dot)com>, Greg Burd <greg(at)burd(dot)me>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values, round two |
| Date: | 2026-09-22 00:07:21 |
| Message-ID: | CALj2ACUbeqMR4V0tjddxLtej=NwdqQy=jbyujdzY+SN9mj4hKg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Mon, Sep 21, 2026 at 3:53 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> > I also attached the 0001 and 0002 from
> > https://www.postgresql.org/message-id/CALj2ACUmBhBGb%2B4d8SRq9JT\_ZsObCAvY6-10CKgSWX98zdv2DQ%40mail.gmail.com
> > here as 0002 and 0003.
>
> Not feeling much about 0002 at this stage. I don't disagree about the
> fact of documenting something, but one has a few more ways to do it,
> one being a CTAS with a WITH clause. You could also drop the varlena
> attributes from a definition (after having migrated the values),
> VACUUM FULL to drop the existing TOAST and add a new text attribute to
> force the creation of a new TOAST table based on the new type wanted,
> after an ALTER TABLE SET.
Agreed. Since we don't exactly know which option works better for
users, having one thing documented in core tends to be taken as the
recommended approach, which I would like to avoid. So, I'm fine to
withdraw this.
> > In the attached 0003, I fixed an issue with the remote version check
> > and simplified the tests by reusing an existing table whose reloption
> > is already reset, and verifying that the dump reports the original
> > TOAST type. This is good enough to cover the new code without starting
> > a new instance just to test this. I also used a join instead of a
> > per-relation lookup in the query to get the TOAST type, which avoids
> > an extra catalog lookup for every table.
>
> I still don't think much about this part, FWIW. That's just switching
> some semantics to a different one which shows unclear benefits (aka it
> is about what we should do on the dump side if we find a reloption set
> or not, vs what's stored on disk).
Agreed here as well. I expect one does not frequently reset the TOAST
reloption in production, especially after knowing that it doesn't
affect the table once created and has the data. If anyone raises this
later, at least there is evidence in this thread that it was
discussed. They can set the reloption to match the TOAST table
chunk_id type if they wish to. So, I'm fine to withdraw this as well.
Apologies for the noise. Thanks.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-09-22 00:12:30 | Re: Add a permission check to pg_stat_get_backend_subxact() |
| Previous Message | shihao zhong | 2026-09-21 23:58:56 | Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity |