Re: Solving the OID-collision problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Solving the OID-collision problem
Date: 2005-08-04 16:20:24
Message-ID: 16384.1123172424@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Mark Woodward" <pgsql(at)mohawksoft(dot)com> writes:
>> 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.

No, you're missing the point entirely: on 32-bit architectures, passing
a 32-bit integral type to a function is an extremely well optimized
operation, as is returning a 32-bit integral type. Passing or
returning a 64-bit struct is, um, not so well optimized.

There's also the small problem that it really has to fit into Datum.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin M. Roy 2005-08-04 16:37:24 Re: US Census database (Tiger 2004FE) - 4.4G
Previous Message Andrew Dunstan 2005-08-04 16:09:33 buildfarm happenings