Denis, I see we still use GridUnsafeMemory in LuceneIndex [1] in master. Do you mean a wrapper to new memory manager is used here?
[1] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridLuceneIndex.java On Tue, Aug 1, 2017 at 10:28 PM, Denis Magda <dma...@apache.org> wrote: > Andrey, > > I’ve already wiped the old off-heap memory out of my mind. Sure I assumed > the off-heap space managed by the new memory architecture. > > — > Denis > > > On Aug 1, 2017, at 11:14 AM, Andrey Mashenkov < > andrey.mashen...@gmail.com> wrote: > > > > Denis, > > > > Lucene fullText index stores off-heap in old way, not in page memory. > > Therefore it is not persistent. > > > > There is a second issue related to FullText index as it is different kind > > of index and it has own query type and it can't be use in SQL queries. > > Looks like it make sense to integrate FullText indices in our SQL layer > as > > well. > > > > AFAIK, H2 has some support of FullText indices based on Lucene, so we can > > get a hint how we can integrate it. > > > > > > > > On Tue, Aug 1, 2017 at 8:09 PM, Denis Magda <dma...@apache.org> wrote: > > > >> Vladimir, > >> > >> We need to consider that these two types of indexes are not stored > >> off-heap either. > >> > >> It expands the task a bit — the indexes have to be fully integrated with > >> the new durable memory architecture supporting both off-heap and > >> persistence layers. > >> > >> — > >> Denis > >> > >>> On Aug 1, 2017, at 3:26 AM, Vladimir Ozerov <voze...@gridgain.com> > >> wrote: > >>> > >>> Guys, > >>> > >>> AFAIK these two index types are not supported with enabled persistence > at > >>> the moment, neither they stored on the disk anyhow. Can someone help > with > >>> estimates on how difficult would it be to implement these indexes over > >>> page-memory architecture? > >>> > >>> Looks like we will have to write our own implementation of these > indexes, > >>> instead of relying on Lucene and H2. Am I right? > >>> > >>> Vladimir. > >> > >> > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > -- Best regards, Andrey V. Mashenkov
