On Wed, Aug 13, 2025 at 03:06:16PM -0500, Jim Nasby wrote:
> On Fri, Aug 8, 2025 at 4:03 PM Andres Freund <andres@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
