Re: removing datlastsysoid - Mailing list pgsql-hackers

From David Steele
Subject Re: removing datlastsysoid
Date
Msg-id e92b1bd7-902a-f4ab-2b6c-5fbeb9657b75@pgmasters.net
Whole thread Raw
In response to Re: removing datlastsysoid  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 5/16/22 11:19 AM, Alvaro Herrera wrote:
> On 2022-May-16, David Steele wrote:
> 
>> On 5/16/22 10:26 AM, Tom Lane wrote:
> 
>>> I think that when we approach the point where the system OID range
>>> is saturated, we'll give up the principle of system OIDs being
>>> globally unique instead of doing that.  There's no fundamental
>>> reason why unique-per-catalog wouldn't be good enough, and letting
>>> that be the standard would give us many more years of breathing room.
>>
>> I'm in favor of global IDs since they help prevent incorrect joins, but
>> agree that what you propose would likely be the least painful solution.
> 
> I just had that property alert me of a bug last week, so yeah.  I wish
> there was a way to keep that at least partially -- say use an individual
> OID counter for pg_proc (the most populous OID-bearing catalog) and keep
> a shared one for all other catalogs.

I have used a similar strategy before. For example, a global sequence 
for all dimension tables and then a per-table sequence for large fact 
tables.

This is not exactly that scenario, but what you are proposing would keep 
most of the benefit of a global ID. pg_proc is not a very commonly 
joined table for users in my experience.

Now we just need to remember all this ten years from now...

Regards,
-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Remove support for Visual Studio 2013
Next
From: Alvaro Herrera
Date:
Subject: Re: First draft of the PG 15 release notes