On Wed, Aug 13, 2025 at 03:06:16PM -0500, Jim Nasby wrote: > On Fri, Aug 8, 2025 at 4:03 PM Andres Freund <and...@anarazel.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.
Yep, that exists. My original use case is not this one, where I have a class of users able to reach the OID limit on a single table even within the 32TB limit, meaning that TOAST blobs are large enough to reach the external threshold, still small enough to have 4 billions of them within the single-table limit. Implementation-wise, switching to 8B would solve both things, and it's so much cheaper to grab a value from a single source. I don't really object to using 4B local values, but that does not really solve the original issue that's causing the efforts I've initiated on this thread. But yes, I'm also trying to implement things so as such an addition like this one would be slightly easier. It just does not have to be me doing it ;) -- Michael
signature.asc
Description: PGP signature
