Re: Performance optimization of btree binary search

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance optimization of btree binary search
Дата
Msg-id 15242.1386255776@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Performance optimization of btree binary search  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Performance optimization of btree binary search
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-12-05 08:58:55 -0500, Tom Lane wrote:
>> I'm a bit worried that somebody, particularly third-party code,
>> might've sloppily written "return foo" in a V1 function when "return
>> Int32GetDatum(foo)" would be correct.  In that case, the resultant Datum
>> might have not-per-spec high-order bits, and if it reaches the fast
>> comparator without ever having been squeezed into a physical tuple,
>> we've got a problem.

> Too bad V1 hasn't insisted on using PG_RETURN_* macros. That would have
> allowed asserts checking against such cases by setting
> fcinfo->has_returned = true or such...

[ shrug... ]  PG_RETURN_DATUM has no practical way to verify that the
given Datum was constructed safely, so I think we'd just be adding
overhead with not much real safety gain.

In practice, if we were to change Datum to be a signed type (intptr_t
not uintptr_t), the most common cases would probably do the right thing
anyway, ie an int or short return value would get promoted to Datum
with sign-extension.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: same-address mappings vs. relative pointers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposal: variant of regclass