pipeline and transactions should not be the same

[twidi]

Since your commit bd411f9 redis-py executes pipelines atomically with MULTI/EXEC commands.
But pipelines and transactions are not the same, redis can handle a pipeline without MULTI/EXEC as before, and sometines it's what we want. After a long talk with Salvatore/Antirez, the two ways should be provided (transactions use more memory and are a bit slower).
Maybe an option to the pipeline command ?

[andymccurdy]

Ya, that probably makes sense.

[twidi]

for example, a pipeline with a lot of sadd or zincr may not need to be atomic

[kmerenkov]

What is a pipeline then if not MULTI/EXEC? There is no other pipeline or transaction in redis.

If you don't need sadd or zincr to be atomic then issue them one by one and you will get exactly what you want.

[andymccurdy]

The benefit to pipelining without MULTI/EXEC would be speed of execution. Think batch data loading.

[twidi]

yes andy got the point

[kmerenkov]

The only difference between Pipeline with MULTI/EXEC removed and sending commands one by one yourself is this:

When you use Pipeline and have 10 commands to send, connection.send (i.e. writing into socket) will be called 1 time (all your commands concatenated).

Without Pipeline for 10 commands connection.send() will be called 10 times. But I think that this is not a serious optimization at all.
You may save on saving one big packet instead of 10 small but... is it that critical? Maybe TCP_NODELAY option ought to be removed (or made optional) instead?

I think it is a false impression of efficiency.

If I got it all wrong, please tell me (because I am really interested).

[twidi]

With thousands of commands, even if it's just a small optimization, it counts... and it's a feature provided by redis so why should we ignore it ?

[kmerenkov]

No we shouldn't. But now it is clear what is needed.
Sounds good!

[andymccurdy]

Pipeines can not optionally be transactions (wrapped in MULTI/EXEC) or not by passing the transaction parameter. This closed by 74d4666.

[andymccurdy]

This has been fixed in 74d4666