From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Yet another fast GiST build |
Date: | 2020-09-09 10:28:43 |
Message-ID: | 21D103AD-E510-4699-8BE5-D462B42A64C8@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks Darafei!
> 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)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?
>
> 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 bigger and 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2020-09-09 10:42:51 | Re: file_fdw vs relative paths |
Previous Message | Amit Kapila | 2020-09-09 10:26:51 | Re: Inconsistency in determining the timestamp of the db statfile. |