Why MGET is not supported?

[Shipeng Feng]

Personally I would say MGET is a big deal, pipelines works but maybe it is not as fast as MGET, is it possible that we could support it ?

The idea is simple, when we get one MGET call, we classify keys according to their redis nodes and send the MGET command to the corresponding node, which happens in parallel.

Mostly we use MGET a lot, maybe it is special enough to be supported as an API ?

[Armin Ronacher]

What would be possible would be to internally automatically use MGET when it makes sense. My tests however did not indicate that MGET would be any more performant than pipelined GET.

[Shipeng Feng]

MGET would be one simpler and handier API. Of course everyone could also do it like this:

def mget(keys):
    results = []
    with cluster.map() as client:  # Assume internally use MGET and assume it is faster
        for key in keys:
            results.append(client.get(key))
    return map(lambda p: p.value, results)

Well, to keep the library clean, you are right :)

[Armin Ronacher]

So I implemented this in two independent layers now.

First of all multiple GET and SET will internally be auto merged into MGET, MSET on the pipeline level. Regardless of if you are using .get or .mget. Secondly promise based clients (like the mapping one) will have an emulated mget / mset command that internally issues multiple get/set calls.

[Shipeng Feng]

👍