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 14:55:21
Message-ID: 15797.1123167321@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:
>> 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. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-08-04 15:12:58 Re: Enhanced containment selectivity function
Previous Message Tom Lane 2005-08-04 14:46:24 Re: prevent encoding conversion recursive error