Hi! In many cases GiST index can be build fast using z-order sorting.
I've looked into proof of concept by Nikita Glukhov [0] and it looks very interesting. So, I've implemented yet another version of B-tree-like GiST build. It's main use case and benefits can be summarized with small example: postgres=# create table x as select point (random(),random()) from generate_series(1,3000000,1); SELECT 3000000 Time: 5061,967 ms (00:05,062) postgres=# create index ON x using gist (point ) with (fast_build_sort_function=gist_point_sortsupport); CREATE INDEX Time: 6140,227 ms (00:06,140) postgres=# create index ON x using gist (point ); CREATE INDEX Time: 32061,200 ms (00:32,061) As you can see, Z-order build is on order of magnitude faster. Select performance is roughly the same. Also, index is significantly smaller. Nikita's PoC is faster because it uses parallel build, but it intervenes into B-tree code a lot (for reuse). This patchset is GiST-isolated. My biggest concern is that passing function to relation option seems a bit hacky. You can pass there any function matching sort support signature. Embedding this function into opclass makes no sense: it does not affect scan anyhow. In current version, docs and tests are not implemented. I want to discuss overall design. Do we really want yet another GiST build, if it is 3-10 times faster? Thanks! Best regards, Andrey Borodin. [0] https://github.com/postgres/postgres/compare/master...glukhovn:gist_btree_build
0001-function-relopt-for-gist-build.patch
Description: Binary data
0003-Implement-GiST-build-using-sort-support.patch
Description: Binary data
0002-Add-sort-support-for-point-gist_point_sortsupport.patch
Description: Binary data
