> "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.
I don't really see this as a problem except in REALLY small installations
and PostgreSQL doesn't have that reputation. Also, we have without oid.
>
> 2. Performance. Doing this would require widening Datum to 64 bits,
> which is a system-wide performance hit on 32-bit machines.
Do you really think it would make a measurable difference, more so than
your proposed solution? (I'm skeptical it would be measurable at all)
>
> 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.
Maybe OID is no longer a number, but is now a structure:
typedef struct _pgOID
{ time_t date; int id;
}OID;
(Not a serious proposal for the contents of the structure)
>
> 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.