Same think stays for the full-text indexes which are currently stored in Lucene.
2017-05-24 21:56 GMT+03:00 Dmitriy Setrakyan <[email protected]>: > Sergi, > > While we are figuring this out, what happens to the GeoSpatial > functionality in the mean time? Is it going to work at all? If not, should > we throw some sort of exception? > > D. > > On Wed, May 24, 2017 at 1:44 AM, Sergi Vladykin <[email protected]> > wrote: > > > Though this may require some changes in BPlusTree. Let me think. > > > > Sergi > > > > 2017-05-24 8:58 GMT+03:00 Sergi Vladykin <[email protected]>: > > > > > It must not be too hard to implement kd-tree over b+tree [1]. Depending > > on > > > level we have to compare either X or Y coordinate. > > > > > > I think we will even have a performance boost for spatial indexes after > > > this change. > > > > > > [1] https://en.wikipedia.org/wiki/K-d_tree > > > > > > Sergi > > > > > > 2017-05-23 18:59 GMT+03:00 Denis Magda <[email protected]>: > > > > > >> +1 > > >> > > >> This looks natural considering that we switched to the new memory > > >> architecture. Sergi, how difficult is to support this? > > >> > > >> — > > >> Denis > > >> > > >> > On May 23, 2017, at 4:25 AM, Sergi Vladykin < > [email protected] > > > > > >> wrote: > > >> > > > >> > Guys, > > >> > > > >> > Looks like we have to move our geospatial indexes to the new > approach > > >> with > > >> > BPlusTree. Right now it stores data in Java heap. This is especially > > >> > important because we are going to have a persistence layer donated > by > > >> > GridGain and obviously geo spatial indexes will not work with it at > > all. > > >> > > > >> > Sergi > > >> > > >> > > > > > >
