Re: OID wraparound: summary and proposal
От | Tom Lane |
---|---|
Тема | Re: OID wraparound: summary and proposal |
Дата | |
Msg-id | 24051.997124888@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: AW: Re: OID wraparound: summary and proposal (Alex Pilosov <alex@pilosoft.com>) |
Список | pgsql-hackers |
Hmm, this has proven more contentious than I expected ;-). It seems the one thing that absolutely everybody agrees on is that 4-byte OIDs are no longer workable as global identifiers. My feeling after reading the discussions is that the best way to go in the long run is to change from a database-wide OID generator to per-table OID generators, and to say that if you want a database-wide unique identifier then you should use <table oid, row oid> as that identifier. If you want cluster-wide or universe-wide uniqueness then you stick additional fields on the front of that. Unique IDs formed in this way are a lot more useful than IDs taken from a simple global sequence, because you can use the subfields to determine where to look for the object. If OID remains at 4 bytes then this still isn't very satisfactory for tables that are likely to have more than 4 billion INSERTs in their lifetime. However, rather than imposing the cost of 8-byte OIDs everywhere, I'd be inclined to say that people who need unique identifiers in such tables should use user-defined columns generated from int8 sequences. (Obviously it would help if we created an int8-based sequence type... but that's certainly doable.) Perhaps in another few years, when all portability and performance issues with int8 are history, we could think about changing OID to 8 bytes everywhere; but I don't think that's a good idea just yet. I do not think it is feasible to try to implement per-table OID generation for 7.2. What I'd like to do for 7.2 is continue with my previous proposal of making OID generation optional on a per-table basis (but the default is still to generate them). This seems to fit well with an eventual migration to per-table OIDs, since it still seems to me that some tables don't need them at all --- particularly, tables that are using an int8 column as key because wraparound is expected. Also, I will change pg_description as previously discussed, since this is clearly necessary in a per-table-OID world. Comments, objections? regards, tom lane
В списке pgsql-hackers по дате отправления: