Re: Yet another fast GiST build
От | Andrey M. Borodin |
---|---|
Тема | Re: Yet another fast GiST build |
Дата | |
Msg-id | 21D103AD-E510-4699-8BE5-D462B42A64C8@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Yet another fast GiST build (Darafei "Komяpa" Praliaskouski <me@komzpa.net>) |
Ответы |
Re: Yet another fast GiST build
|
Список | 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 по дате отправления: