Request for feature HMINCRBY

[GoogleCodeExporter]

What version of Redis you are using, in what kind of Operating System?
Redis 2.2.4 on Linux - Debian - AMD-64

What is the problem you are experiencing?
Not an issue - asking for a new feature

What steps will reproduce the problem?
NA.

Do you have an INFO output? Please past it here.
NA.

If it is a crash, can you please paste the stack trace that you can find in
the log file or on standard output? This is really useful for us!

Please provide any additional information below.
I am writing an app that has a large hashtable with <String, Integer> format.  
I want to push it all into redis in one shot using HMINCRBY instead fo HINCRBY 
+ pipelining.  

Original issue reported on code.google.com by venugopa...@gmail.com on 15 Apr 2011 at 4:21

[GoogleCodeExporter]

Do you want to push static values like HMSET? Or do you want to increment as 
your feature request suggests?

Generally, the response in the last year to feature requests for bulk calls has 
been "use pipelining with optional multi/exec".

Original comment by josiah.c...@gmail.com on 15 Apr 2011 at 5:05

[GoogleCodeExporter]

I want to increment on an ongoing basis - the scenario is something like this.  
I have a redis hash with say 100 entries of <String, int> combination.  then I 
want to add to this more data from another collection of <string, int>  this 
would either add to the entry in redis hash if it already exists or create a 
new entry if the key does not exist.

I am using HINCRBY + pipelining today.  Since I saw HSET/HMSET I assumed for 
the sake of symmetry I thought HMINCBY would be present (assuming there are 
performance advantages of doing so)

Original comment by venugopa...@gmail.com on 16 Apr 2011 at 12:42

[GoogleCodeExporter]

Almost a year ago, I had proposed scardmulti, which got the cardinality of 
multiple sets passed. Using Python against a local Redis, the use of the custom 
command vs. a pipelined command was about 2x faster using the custom command. 
That also included Python request construction and response processing, etc., 
which more than likely was the primary slowdown. I suspect that if you were to 
do a similar experiment now, you would find that pipelined requests vs. a 
custom command to be within 10-20% of one another (ignoring client processing).

Original comment by josiah.c...@gmail.com on 18 Apr 2011 at 5:40

[GoogleCodeExporter]

So is that the new model for REDIS?  to move aways from the Mxxx commands and 
use  pipelining commands?  

Original comment by venugopa...@gmail.com on 20 Apr 2011 at 1:46

[GoogleCodeExporter]

I don't know if existing xMxxx commands will ever go away, but I've not seen 
any new ones in over a year.

Original comment by josiah.c...@gmail.com on 20 Apr 2011 at 8:28

[GoogleCodeExporter]

The new model (as of 2.4) is rather variadic commands, which means that in your 
case you could use something like:

    HINCRBY key field1 increment1 field2 increment2 ...

The old HINCRBY will then only be a special case of this more generic one.

Original comment by catwell...@gmail.com on 20 Apr 2011 at 12:59