Re: Solving the OID-collision problem

From: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Solving the OID-collision problem
Date: 2005-08-04 17:34:01
Message-ID: 22592.24.91.171.78.1123176841.squirrel@mail.mohawksoft.com
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.

That's only if you call by value, call by reference is just as optimized.

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

Would it break a lot if you add more to a datum?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message mark 2005-08-04 17:55:04 Re: Solving the OID-collision problem
Previous Message Mark Woodward 2005-08-04 17:32:13 Re: pg_dump -- data and schema only?