Re: Solving the OID-collision problem

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