|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>|
|Cc:||"Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, 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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote:
> On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> 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:
Thanks, that's interesting.
I implemented the abbreviated keys for the point opclass, too, and
noticed that the patch as it was never used it. I reworked the patch so
that tuplesort_begin_index_gist() is responsible for looking up the
sortsupport function, like tuplesort_begin_index_btree() does, and uses
abbreviation when possible.
I think this is pretty much ready for commit now. I'll do a bit more
testing (do we have regression test coverage for this?), also on a
SIZEOF_DATUM==4 system since the abbreviation works differently with
that, and push if nothing new comes up. And clarify the documentation
and/or comments that the sortsupport function sees "compressed" values.
I wonder if we could use sorting to also speed up building tsvector
indexes? The values stored there are bit signatures, what would be a
good sort order for those?
|Next Message||Alvaro Herrera||2020-09-09 16:01:26||Re: Inconsistency in determining the timestamp of the db statfile.|
|Previous Message||Heikki Linnakangas||2020-09-09 15:39:21||Re: Yet another fast GiST build|