Re: Solving the OID-collision problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Solving the OID-collision problem
Дата
Msg-id 16384.1123172424@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Solving the OID-collision problem  ("Mark Woodward" <pgsql@mohawksoft.com>)
Ответы Re: Solving the OID-collision problem  ("Mark Woodward" <pgsql@mohawksoft.com>)
Re: Solving the OID-collision problem  (mark@mark.mielke.cc)
Список pgsql-hackers
"Mark Woodward" <pgsql@mohawksoft.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: buildfarm happenings
Следующее
От: "Gavin M. Roy"
Дата:
Сообщение: Re: US Census database (Tiger 2004FE) - 4.4G