Hi.
There is another similar case, what if update actually change nothing?
BEGIN;
INSERT INTO person(id, name) VALUES(1, 'ivan');
UPDATE person SET name = 'ivan' WHERE id = 1;
COMMIT;
Should it we take into account both operations or not?
I'd think current implementation is correct one as
TX
Hi team,
I need you opinion again. I wrote some tests for metrics and felt a
confusion with metrics count for the same key update during transaction.
Imagine following case:
BEGIN;
INSERT INTO person(id, name) VALUES(1, 'ivan');
UPDATE person SET name = 'vanya' WHERE id = 1;
COMMIT;
My
Hi Alex,
Thank you for referring spec. It really gives strict point how JCache
metrics should be counted.
So, I will start implementation of metrics for MVCC caches according to
spec and existing behavior.
As for improper "removals" calculation, I filed a ticket
Hi, Ivan
Looks like a bug. Metrics counting described at JSR107 (JCache)
specification. It says, that "cache removals" metric should be incremented
if remove() method returns true. Since there are no matching keys in the
first remove() call should be found, remove() should return false and
"cache
Hi,
Dmitriy thanks for note, I will keep metrics IEP in mind.
Roman it sounds quite a straightforward approach. Moreover current cache
transactions follow it: there could be a number of invisible actions in
private workspace (e.g. creating and then deleting the same entry) but only
final changes
I think we should be updating the IEP with metrics specifications in
parallel.
D.
On Wed, Aug 8, 2018, 05:32 Roman Kondakov
wrote:
> Hi Ivan!
>
> In my opinion we need to preserve the essence of the metrics: if we
> didn't consider dirty writes as updates before MVCC implementation, we
> also
Hi Ivan!
In my opinion we need to preserve the essence of the metrics: if we
didn't consider dirty writes as updates before MVCC implementation, we
also shouldn't count these writes in MVCC metrics implementation too.
So, I think we need to count only committed entries. But we can count
this
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
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, Павлухин Иван wrote:
> Hi Igniters,
>
> I am working on cache metrics support for caches with enabled MVCC. As you
> may know, during MVCC transaction execution
