Re: Solving the OID-collision problem

> "Mark Woodward" <pgsql(at)mohawksoft(dot)com> writes:
>>> 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)
>
> I'm too lazy to run an experiment, but I believe it would. Datum is
> involved in almost every function-call API in the backend. In
> particular this means that it would affect performance-critical code
> paths.

I hear you on the "lazy" part, but if OID becomes a structure, then you
are still comparing a native type until you get a match, then you make one
more comparison to confirm it is the right one, or move on. I think it is
a small hit that wouldn't even be noticed.

In fact, thinking about it....

typedef struct _pgOID
{
OLDOID_TYPE oldOID;
time_t unique;
}OID;

Everything works as it did before except that there is 32 bit date
identifier to prevent wrap around. Just one additional check is needed
only if there is a wrap.

> Creation of tables and such isn't performance-critical in most
> applications, so a few percent overhead there doesn't bother me. A few
> percent across the board is another story.

Compared to all the other things going on, I would bet it isn't even
measuable.