John Sully

We fail the test: > client can't subscribe to multiple shard channels across different slots in same call Since the intent is to allow crossslot I need to investigate if...

We have use cases that we simply can't run without this so pretty important for very high scale jobs. Will dive into the pubsub issue but I can't think of...

What was the rationale to not permit read modify write?

> One question we did want to understand was the actual performance benefit of this. In the other thread we discussed whether or you could just do a deep pipeline...

Ah you are looking at it from the perspective of greater order atomics. This is not designed to allow that and it doesn't since at any time you can get...

Pipeline of 10 it closes up a bit but still a win: ``` SET: 1136363.62 requests per second, p50=0.375 msec MSET (10 keys): 440528.62 requests per second, p50=1.127 msec ```...

My experiments with prefetch were mostly failures but its always something that rolls around in the back of your head. I'm going to clean this one up since its really...

@PingXie re changing the contract it is only additive. So it should not be a back compatibility problem. I.e. cases that use to be errors are now accepted but no...

@zuiderkwast The code is correct in KeyDB but i will check if anything has changed enough to break it. However we check hash slots for both the first and all...

@zuiderkwast I will modify the change to only permit crossslot on reads. This should eliminate the issue of needing current_slot since you only need to update the counts on write.