| From: | Jim Nasby <jnasby(at)upgrade(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, "Burd, Greg" <greg(at)burd(dot)me>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) |
| Date: | 2025-08-13 20:06:16 |
| Message-ID: | CAMFBP2oHjJjTvp2a-ty9eZA=Shq9DVTNEdae9UGamZ7y=cK7XQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Aug 8, 2025 at 4:03 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I'm not convinced that the global counter, be it a 32 or a 64 bit, approach
> has merit in general, and I'm rather sure it's the wrong thing for toast
> values. There's no straightforward path to move away from the global
> counter
> for plain oids, but I would suggest simply not using the global oid counter
> for toast IDs.
>
> A large portion of the cases I've seen where toast ID assignments were a
> problem were when the global OID counter wrapped around due to activity on
> *other* tables (and/or temporary table creation). If you instead had a
> per-toast-table sequence for assigning chunk IDs, that problem would
> largely
> vanish.
>
That's been my experience as well. I was actually toying with the idea of
simply switching from OIDs to per-table counters when I came across this,
specifically to address the problem of OID wraparound induced performance
problems.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2025-08-13 20:27:04 | Re: cfbot mistakenly reports that a rebase is needed |
| Previous Message | Tom Lane | 2025-08-13 20:04:06 | Re: Making type Datum be 8 bytes everywhere |