[postgis-devel] Advancing GiST in PgSQL

Paul Ramsey pramsey at cleverelephant.ca
Mon Jul 30 06:29:46 PDT 2018


On Sat, Jul 28, 2018 at 3:36 AM, Andrey Borodin <x4mmm at yandex-team.ru> wrote:
> 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])

How would an extension deal with gist-as-extension, assuming it also
wanted to use gist-as-built-in in cases where the extension version
wasn't around? (Also, some fun version issues there, as presumably a
goal of gist-as-extension would be provided a faster feature pace than
stock PgSQL).
Just register different functions in the opclass, yes?

> 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.

Multi-key support as you noted, can be useful. Indexing any large
object gets less efficient as the amount of area the keys cover goes
upwards.

A join that doesn't have to nested loop might be interesting. Not sure
the extent to which merging two gist trees can be done (assuming they
are built using the same opclass maybe?) but anything that speeds up
joins a little is nice.

> 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?

Hard to say. It's not clear to me that indexes are our biggest pain
point, they work acceptably well, as is. The exception is probably the
large/small issues that a multi-key approach could address. For that
we could also take a run at a GIN implementation, but the extreme
simplicity of the GIN keys make that a bit tricky.

P.


>
> Thanks for reading :) Looking forward for your reply.
>
> Best regards, Andrey Borodin.
>
> [0] https://github.com/x4m/ags
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel


More information about the postgis-devel mailing list