From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: removing datlastsysoid |
Date: | 2022-05-16 15:31:55 |
Message-ID: | e92b1bd7-902a-f4ab-2b6c-5fbeb9657b75@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-05-16 15:41:08 | Re: First draft of the PG 15 release notes |
Previous Message | Tom Lane | 2022-05-16 15:23:15 | Re: Remove support for Visual Studio 2013 |