0

According to Redis documentation on PFADD command:

 Return value
 Integer reply, specifically:
 1 if at least 1 HyperLogLog internal register was altered. 0 otherwise.

Can anyone explain the following two points?

  1. Does this mean PFADD will return "1" if the counter was really incremented by 1? is it guaranteed that after running PFADD, the new PFCOUNT will be PFCOUNT(before) + output of PFADD? In other words, can a single-threaded client keep track of the count using only the output of PFADD?
  2. When PFADD returns "0" or "1", do they translate to a "cache hit" and a "cache miss" respectively?
mjalajel
  • 2,171
  • 21
  • 27

1 Answers1

3

Does this mean PFADD will return "1" if the counter was really incremented by 1?

No.

The return value is purely boolean, i.e it only indicates whether or not the underlying HyperLogLog was modified.

Is it guaranteed that after running PFADD, the new PFCOUNT will be PFCOUNT(before) + output of PFADD?

No, since the output of PFADD does not represent a count (see above).

That being said, you may want to use the output of PFADD as a trigger to call PFCOUNT again, as explained by antirez in the original blog post:

This is interesting for the user since as we add elements the probability of an element actually modifying some register decreases. The fact that the API is able to provide hints about the fact that a new cardinality is available allows for programs that continuously add elements and retrieve the approximated cardinality only when a new one is available.

At last:

When PFADD returns "0" or "1", do they translate to a "cache hit" and a "cache miss" respectively?

No. As detailed above it only indicates that a new cardinality is available.

deltheil
  • 15,496
  • 2
  • 44
  • 64
  • A followup clarification: Is it okay to assume when PFADD returns 1 (i.e. the state registers were modified), a new item was added with 99% accuracy? – Dickey Singh Jul 30 '15 at 20:31