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

From Andrey M. Borodin
Subject Re: Yet another fast GiST build
Date
Msg-id 21D103AD-E510-4699-8BE5-D462B42A64C8@yandex-team.ru
Whole thread Raw
In response to Re: Yet another fast GiST build  (Darafei "Komяpa" Praliaskouski <me@komzpa.net>)
Responses Re: Yet another fast GiST build
List pgsql-hackers
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
comparatorroutine: 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? 
>
> Currently we pass compressed values, which seems not very good.
> But there was a request from PostGIS maintainers to pass values before decompression.
> Darafei, please, correct me if I'm wrong. Also can you please provide link on PostGIS B-tree sorting functions?
>
> We were expecting to reuse btree opclass for this thing. This way btree_gist extension will become a lot thinner. :)

I think if we aim at reusing B-tree sort support functions we have to pass uncompressed values. They can be a lot
biggerand slower in case of PostGIS. We will be sorting actual geometries instead of MBRs. 

In my view it's better to implement GiST-specific sort support in btree_gist, rather than trying to reuse existing sort
supports.

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Inconsistency in determining the timestamp of the db statfile.
Next
From: Magnus Hagander
Date:
Subject: Re: file_fdw vs relative paths