Dmitry, As with MVCC we can have multiple versions of each tuple at the same time it introduces storage overhead. It would be good to have a measure for such overhead. Another thing is related to VACUUM procedure. For protecting system from crash in case of high load it would be great to detect that VACUUM cleanup cannot keep up with new tuple versions creation rate.
Currently it is just raw thoughts, I continue learning Ignite metrics framework. 2018-08-08 1:12 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > Ivan, > > To your 2nd question, can you suggest a few MVCC metrics to get the > discussion started? > > D. > > On Tue, Aug 7, 2018 at 9:17 AM, Павлухин Иван <vololo...@gmail.com> wrote: > > > Hi Igniters, > > > > I am working on cache metrics support for caches with enabled MVCC. As > you > > may know, during MVCC transaction execution entry versions are written to > > storage right away (without deferring until commit). So, it is not > obvious > > for me if we should update writes count right away or defer it until > > commit. On one hand, MVCC entry version write is not "true" write until > > commit. On the other hand, it definitely changes the storage. How do we > > interpret write metrics in Ignite philosophy? > > > > Also, it seems that bunch of MVCC specific metrics could be introduced. I > > would like to collect some thoughts about it. Which such metrics come to > > your mind? > > > > -- > > Best regards, > > Ivan Pavlukhin > > > -- Best regards, Ivan Pavlukhin
