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

From Darafei "Komяpa" Praliaskouski
Subject Re: Yet another fast GiST build
Date
Msg-id CAC8Q8t+KG6oeyC697X3agZmHFTMjZYKvg13X2KapbfcTiYvdhw@mail.gmail.com
Whole thread Raw
In response to Re: Yet another fast GiST build  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Yet another fast GiST build
Re: Yet another fast GiST build
List 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



 

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Inconsistent Japanese name order in v13 contributors list
Next
From: Michael Paquier
Date:
Subject: Re: Online checksums verification in the backend