<div dir="ltr">Hi!<br><br><div class="gmail_quote"><div dir="ltr">сб, 28 июл. 2018 г. в 13:44, Andrey Borodin <<a href="mailto:x4mmm@yandex-team.ru">x4mmm@yandex-team.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
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])<br></blockquote><div><br></div><div>How do you see a process of PostGIS depending on your gist-as-extension?</div><div><br></div><div>Is it going to be part of core? </div><div><br></div><div>Why will it live long and prosper? :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW, 2 and 3 are on current commitfest and everyone is very welcome to review them. 2 is very tiny, less than 100loc.<br></blockquote><div><br></div><div>Can you provide a commitfest link?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>There is btree_gist contrib. A good solution, IMHO, would be to make it indistinguishable from the "real" btree. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
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.<br></blockquote><div><br></div><div>A big question is "Problem of Russia" - Russia spans over 180 meridian, and its box covers all of Europe and US. Any indexed query in that area keeps rechecking full contour of Russia, slowing everything down. It would be good if indexing machinery can cope with several bounding boxes living in different parts of index, each coverting much smaller area.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>A thing I'm afraid of is maintenance of extension for newer Postgres versions, and dependency management with PostGIS. </div></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa">http://patreon.com/komzpa</a></div></div>