"Mark Woodward" <[EMAIL PROTECTED]> writes: > Why is there collision? It is because the number range of an OID is > currently smaller than the possible usage.
Expanding OIDs to 64 bits is not really an attractive answer, on several grounds: 1. Disk space. 2. Performance. Doing this would require widening Datum to 64 bits, which is a system-wide performance hit on 32-bit machines. 3. Portability. We still manage to run on machines that have no 64-bit int type at all, and I for one am not prepared to give that up until it's necessary. Given that we've agreed to deprecate use of OIDs in user tables, I don't see any particular upside to making them 64 bits anyway. None of the system catalogs seem likely to ever contain enough entries that a 32-bit limit is a problem. These are all more or less the same arguments as concern 64-bit transaction IDs. The hacks we've indulged in to avoid that are far nastier and more invasive than what I'm suggesting for OIDs (vacuuming to forestall XID wraparound is certainly pretty ugly, and it's even user-visible). Perhaps at some point there will be a "64-bit build option" to make all these data types widen to 64 bits together. I don't really foresee it happening in the near future though (even on 64-bit hardware, I doubt the performance tradeoffs are very favorable). And abandoning support for the 32-bit universe altogether is surely a long way away. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings