Re: Yet another fast GiST build - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Yet another fast GiST build
Date
Msg-id 7DE8A009-5F8E-4D87-8E53-AC91E473DCD4@yandex-team.ru
Whole thread Raw
In response to Re: Yet another fast GiST build  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Yet another fast GiST build
List pgsql-hackers
Thanks for the investigation, Heikki.

> 8 апр. 2021 г., в 01:18, Heikki Linnakangas <hlinnaka@iki.fi> написThe correct pattern would be something like this
(withoutthe debugging NOTICE, of course): 
>
>> static int
>> gbt_text_sort_build_cmp(Datum a, Datum b, SortSupport ssup)
>> {
>>     GBT_VARKEY_R ra = gbt_var_key_readable((GBT_VARKEY *) PG_DETOAST_DATUM(a));
>>     GBT_VARKEY_R rb = gbt_var_key_readable((GBT_VARKEY *) PG_DETOAST_DATUM(b));
>>     int x = DatumGetInt32(DirectFunctionCall2Coll(bttextcmp,
>>                                                  ssup->ssup_collation,
>>                                                  PointerGetDatum(a),
>>                                                  PointerGetDatum(b)));
>>     elog(NOTICE, "cmp: %s vs %s: %d",
>>          TextDatumGetCString(ra.lower),
>>          TextDatumGetCString(rb.lower),
>>          x);
>>     return x;
>> }
>

In this pattern I flipped PointerGetDatum(a) to PointerGetDatum(ra.lower), because it seems to me correct. I've
followedrule of thumb: every sort function must extract and user "lower" somehow. Though I suspect numeric a bit. Is it
regularvarlena? 
PFA patchset with v6 intact + two fixes of discovered issues.

Thanks!

Best regards, Andrey Borodin.


Attachment

pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: Re: Query regarding RANGE Partitioning
Next
From: vignesh C
Date:
Subject: Re: Identify missing publications from publisher while create/alter subscription.