Dima, None database I know use separate regions for index pages due to the reason I expressed above. Instead, they split all pages into two groups - hot and cold. With certain rules on how to move pages inside and between these groups. None of these algorithms are complex enough. In fact, they are pretty straightforward and battle-tested. When implemented properly it doesn't matter whether the page is index page or data page. The only thing that matter is how often it is accessed. This is critical piece that we lack in the product - our policy is called "random *LRU*", while in reality is not LRU at all.
As far as index pages replacement we do not know whether this is problem at all. We heard some complaints that it might be a problem. But we didn't see any proofs (thanks to lack of monitoring) and even if this is a problem, we do not understand how severe it is. May be it adds 1% overhead and can be ignored for years, may be it adds 1000% overhead and must be fixed immediately. This is sensitive piece of a product. Let's use objective data, not assumptions. On Thu, Aug 16, 2018 at 12:08 PM Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > On Thu, Aug 16, 2018 at 2:01 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Hi Dima, > > > > Putting index pages in separate region is wrong approach, because data > > pages may be equally important on certain workloads, especially in > > heap-organized databases, such as Ignite > > > Never seen a use case where the data page was more important than the index > page. I think we are getting into a hypothetical land. Most Ignite users > are having the reverse problem - index pages get evicted in the same way as > data pages. > > Currently, we are solving it in a most awkward way by trying to give index > pages a different eviction policy. A right solution would be to stick them > into a different region and control the eviction policy for the index > region separately from the data region. > > D. >
