Sorry if this is intended and I've just missed why, but in a bit of testing recently I noticed that while transactional pipelining of INSERTs/UPSERTs works great (i.e. they return almost instantly when run within a transaction), it doesn't appear to work for DELETEs (i.e. they have to wait for a full replication round trip).

I noticed this on a cluster running v20.2.7 with roughly 30ms RTT between localities in the cluster.

@nvanbenschoten is this expected? Sorry if it's a dupe or I'm way off base here, but it's surprising to me that inserts/upserts can be pipelined but not deletes.

Reproduction

Create a simple table:

root@/defaultdb> create table foo (k string primary key, v string);

Single inserts, upserts, and deletes all take around 30ms, corresponding with the network latency between localities:

root@/defaultdb> insert into foo values ('a', 'a')
INSERT 1

Time: 31ms total (execution 31ms / network 0ms)

Within a transaction, inserts and upserts finish basically immediately, as I'd expect due to transactional pipelining:

root@/defaultdb> begin;
BEGIN

Time: 0ms total (execution 1ms / network 0ms)

root@/defaultdb  OPEN> insert into foo values ('c', 'a'), ('d', 'a');
INSERT 2

Time: 2ms total (execution 2ms / network 0ms)

root@/defaultdb  OPEN> commit;
COMMIT

Time: 31ms total (execution 31ms / network 0ms)

However, delete statements don't appear to benefit from this optimization:

root@/defaultdb> begin;
BEGIN

Time: 0ms total (execution 0ms / network 0ms)

root@/defaultdb  OPEN> delete from foo where k = 'c';
DELETE 1

Time: 30ms total (execution 30ms / network 0ms)

root@/defaultdb  OPEN> commit;
COMMIT

Time: 31ms total (execution 31ms / network 0ms)

Jira issue: CRDB-7218