Re: Yet another fast GiST build
От | Darafei "Komяpa" Praliaskouski |
---|---|
Тема | Re: Yet another fast GiST build |
Дата | |
Msg-id | CAC8Q8t+KG6oeyC697X3agZmHFTMjZYKvg13X2KapbfcTiYvdhw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Yet another fast GiST build (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Yet another fast GiST build
Re: Yet another fast GiST build |
Список | pgsql-hackers |
On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 09/09/2020 13:28, Andrey M. Borodin wrote:
> Thanks Darafei!
>
>> 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski
>> <me@komzpa.net> написал(а):
>>
>>> How does the 'sortsupport' routine interact with
>>> 'compress'/'decompress'? Which representation is passed to the
>>> comparator routine: the original value from the table, the
>>> compressed representation, or the decompressed representation? Do
>>> the comparetup_index_btree() and readtup_index() routines agree
>>> with that?
>>
....
Come to think of it, the point z-order comparator could benefit a lot
from key abbreviation, too. You could do the point -> zorder conversion
in the abbreviation routine.
That's how it works in PostGIS, only that we moved to more effecient Hilbert curve:
https://github.com/postgis/postgis/blob/54399b9f6b0f02e8db9444f9f042b8d4ca6d4fa4/postgis/lwgeom_btree.c#L171
https://github.com/postgis/postgis/blob/54399b9f6b0f02e8db9444f9f042b8d4ca6d4fa4/postgis/lwgeom_btree.c#L171
В списке pgsql-hackers по дате отправления: