Re: removing datlastsysoid
| От | David Steele |
|---|---|
| Тема | Re: removing datlastsysoid |
| Дата | |
| Msg-id | e92b1bd7-902a-f4ab-2b6c-5fbeb9657b75@pgmasters.net обсуждение исходный текст |
| Ответ на | Re: removing datlastsysoid (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | 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 по дате отправления: