Re: Yet another fast GiST build

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: Yet another fast GiST build
Дата
Msg-id 82884CC2-4C32-41A1-A28C-D35964B9AC68@yandex-team.ru
обсуждение исходный текст
Ответ на Re: Yet another fast GiST build  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Yet another fast GiST build  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Thanks!

> 27 окт. 2020 г., в 16:43, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> gbt_ts_cmp(), gbt_time_cmp_sort() and gbt_date_cmp_sort() still have the above issue, they still compare "upper" for
nogood reason. 
Fixed.

>> +static Datum
>> +gbt_bit_abbrev_convert(Datum original, SortSupport ssup)
>> +{
>> +       return (Datum) 0;
>> +}
>> +
>> +static int
>> +gbt_bit_cmp_abbrev(Datum z1, Datum z2, SortSupport ssup)
>> +{
>> +       return 0;
>> +}
>
> If an abbreviated key is not useful, just don't define abbrev functions and don't set SortSupport->abbrev_converter
inthe first place. 
Fixed.
>
>> static bool
>> gbt_inet_abbrev_abort(int memtupcount, SortSupport ssup)
>> {
>> #if SIZEOF_DATUM == 8
>>     return false;
>> #else
>>     return true;
>> #endif
>> }
>
> Better to not set the 'abbrev_converter' function in the first place. Or would it be better to cast the float8 to
float4if SIZEOF_DATUM == 4? 
Ok, now for 4 bytes Datum we do return (Datum) Float4GetDatum((float) z);

How do you think, should this patch and patch with pageinspect GiST functions be registered on commitfest?

Thanks!

Best regards, Andrey Borodin.

Вложения

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

Предыдущее
От: John Naylor
Дата:
Сообщение: document deviation from standard on REVOKE ROLE
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Assertion failure when ATTACH partition followed by CREATE PARTITION.