Adding a Count Index to a Predicate Causes Transaction Aborts when writing concurrently

[rahst12]

Adding a count index to a predicate causes transaction aborts when a client is writing to the same predicate concurrently in two or more different threads.

[rahst12]

A little claude code research:

Why count updates cause transaction conflicts?

  From posting/list.go:885-887:
  case pk.IsCountOrCountRev():
      conflictKey = getKey(key, t.ValueId)

  The count index key structure is CountKey(attr, count_value, reverse). When entity 0x1 has friend count of 5 and a new edge is added:
  1. DEL: remove 0x1 from the posting list at CountKey("friend", 5) — conflict key = fingerprint(CountKey(friend,5)) ^ 0x1
  2. SET: add 0x1 to the posting list at CountKey("friend", 6) — conflict key = fingerprint(CountKey(friend,6)) ^ 0x1

  Two concurrent transactions adding different edges to the same node both read count=5, both attempt the same DEL-on-5 / SET-on-6 mutations for entity 0x1. They produce identical conflict
  keys → Zero aborts one.

  This is the "hot node" problem: any popular node receiving concurrent edge additions conflicts on the count key for that node. Each add-edge mutation must read the current count, and two
  mutations starting from the same base count cannot both succeed. The more concurrent writes to the same node's edge set, the higher the abort rate.