[postgis-devel] Advancing GiST in PgSQL

Andrey Borodin x4mmm at yandex-team.ru
Sat Jul 28 03:36:50 PDT 2018


Hi!

I'm working on GiST advancement and hacked out some patches, now I'm trying to push them into upstream. But it is a long and tedious process, so I've come up with idea to make fork of a GiST as extension (you can check out very crude prototype here [0])
Initial version will include:
1. Intra-page indexing: faster inserts, somewhat faster searches
2. Covering indexes: create index on a(b) include (c,d,e,f)
3. Better VACUUM: hopefully you will not need to repack GiST that often

BTW, 2 and 3 are on current commitfest and everyone is very welcome to review them. 2 is very tiny, less than 100loc.
All these things are already implemented. But I'm looking for more ideas. Darafei Praliaskouski shared with me some ideas on bulk loading, so I'm going to implement them too.
As far as I know PostGIS is the main consumer for Generalized index Search Trees, so, after all, may be we do not need too generalized index.
If you have some ideas what can be done better in indexing, I'll appreciate if you share them with me. Currently I'm just doing things faster and more efficient.
May be you know some new joins you want, some different searches, some spatio-temoral capabilities of the indexing etc.

Index-as-extension will use generic WAL, so I expect it to be a bit less write-efficient from the start, but algorithmic improvements will cover that.
This index will be used with existing functions for opclasses, but require some new functions for advances functions. Currently it works like this:
CREATE OPERATOR CLASS ags_cube_ops
   DEFAULT FOR TYPE cube USING ags AS -- then all usual functions from cube opcalss

Another open question is how to call it. Currently I use Advanced Generalized Search - AGS as codename, but looking for better names. May be something like Evolution Generalized Search - EGS. Currently, I couldn't come up with fancy name like RUM or GIN :)  I do not think it will be limited just to GiST-like indexes, this is why I removed T (stands for tree). And, if index will be just PostGIS-specialized, G will be removed too. Darafei suggested that I should not use abbreviation, just pick an own name. Also he suggested "ox".

And finally, most important question: will it be useful as extension? Does this idea worth efforts? Are there any problems which will make this extension unusable?

Thanks for reading :) Looking forward for your reply.

Best regards, Andrey Borodin.

[0] https://github.com/x4m/ags


More information about the postgis-devel mailing list