"Mark Woodward" <pgsql@mohawksoft.com> 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