Implement new ADO.NET batching API

[bgrainger]

From comment:

MySqlBatch shipped in 0.57.0; keeping this issue open to track implementing the abstract base classes and virtual methods.

---

The new API is defined in https://github.com/dotnet/corefx/issues/35135.

It seems like the general approach should be to concatenate all SQL from all commands in the batch into one string, substituting parameter values as we go. (That is, this doesn't provide any advantage over what the user can manually do already, but ensures that MySqlDbBatch isn't needlessly inefficient for database-independent code.)

Special attention will need to be taken if the user is mixing CommandType.Text and StoredProcedure in one batch, particularly if the stored procedure has out parameters.

• Do any MySQL Servers support batched prepared (binary) statements, or will the SQL still need to be parsed and split into individual statements if Prepare is called?

A WIP PR is available in #637.

[bgrainger]

Do any MySQL Servers support batched prepared (binary) statements, or will the SQL still need to be parsed and split into individual statements if Prepare is called?

Tested MySQL 8.0.16 and MariaDB 10.4.5 and neither supports it. (They both return an ERR packet with the message "You have an error in your SQL syntax".) Moreover, it seems extremely unlikely to ever be supported based on the protocol definition: COM_STMT_PREPARE_OK contains just one num_columns field. Preparing multiple commands would imply sending multiple result sets, each of which might have a different number of columns; a single num_columns field can't represent this.

Alternatively, perhaps the commands would have to be prepared individually (once), then could be executed (multiple times) as a batch. However, COM_STMT_EXECUTE doesn't permit this, because it has a single stmt-id field.

Thus, for prepared statements it appears that they need to be prepared individually, then executed individually.

[bgrainger]

MariaDB invented a COM_MULTI protocol extension, which looks as if it could be used to support batching, including for prepared statements.

[roji]

That's great! Do you think you're going to be able to attempt an implementation over this anytime soon?

[bgrainger]

I'd like to, but I suspect it will need a fairly significant overhaul of the current command execution and MySqlDataReader processing subsystem. (I'm glad I didn't start yet, because the discovery of COM_MULTI is changing how I will approach it.)

[roji]

That makes sense, batching isn't just a feature you add easily. FWIW the combination of batching and prepared binary statements could be a big step forward for perf, especially if one day you do decide to persist prepared statements. Although the real question is what kind perf increase preparation delivers on MySQL (on PG it's quite decisive).

[bgrainger]

Simple prepared commands are already supported and persisted. I also added it to TFB benchmarks: TechEmpower/FrameworkBenchmarks#4015

However, although local profiling of MySQL Server shows that 17% of statement execution time is spent in SQL parsing (and preparing statements should theoretically eliminate this), there was no appreciable throughput increase in TFB. (And I don't think that any of the top MySQL entrants are using prepared commands to achieve their speed.)

[roji]

OK, thanks for the info - I'm guessing more investigation/experimentation would be needed to understand exactly what's going on. It would be quite strange if prepared statements were supported by MySQL but had no (noticeable) perf advantages.

[bgrainger]

I've got a simplistic version of batching (using MariaDB's COM_MULTI) working now in #637.

Some benchmark code and results are at https://gist.github.com/bgrainger/0504a52065eeade9e4b30e88b6363f2c.

The DbBatch API hasn't caused any problems so far, although I haven't implemented CommandTimeout yet, which (from experience) will be complicated.

I'm not confident that I can implement DbException.BatchCommand in MySqlConnector. If a problem occurs, the MySQL Server will just put an ERR packet on the wire and I can't think of a good way to map it back to the DbBatchCommand object that caused the error.

CC @roji

[roji]

@bgrainger great to see this work! If I'm understanding correctly, at this point your batching implementation only does concatenation batching via text mode, right? And PreparedCommandsBatch would be the one actually batching in binary mode without any concatenation?

Timeouts are indeed notoriously tricky, but I'm curious if batching introduces any specific difficulties that you don't encounter with regular non-batched command execution.

Re DbException.BatchCommand, it's expected that not all providers will support all features. Just for comparison, PostgreSQL doesn't actually have a batch-specific protocol message: multiple Execute messages are simply pipelined one after the other. This means Npgsql receives the results of earlier Execute messages, and only then receives an error, allowing it to know which statement triggered the failure. PostgreSQL does have a useful protocol sync feature: after all Execute messages, Npgsql inserts a Sync messages, which tells PostgreSQL that in case of error all subsequent messages are discarded until that one.

In any case, am looking forward to seeing the results for PreparedCommandsBatch! And obviously post back if you have any feedback on the batching API shape.

[bgrainger]

If I'm understanding correctly, at this point your batching implementation only does concatenation batching via text mode, right?

No; for MariaDB, MySqlBatch will send all the queries (as separate commands, not concatenated SQL) in one "batch" packet. (This is just for the text protocol, no prepared statements.)

I haven't yet written the code to concatenate SQL for a batch sent to MySQL Server, but that is my planned implementation for non-MariaDB servers.

And PreparedCommandsBatch would be the one actually batching in binary mode without any concatenation?

Yes, that's the plan.

BTW, MariaDB allows multiple kinds of commands to be batched; for example a "prepare statement" and "execute statement" can be grouped and executed in one batch. There's also a (separate) bulk insert command that allows one prepared insert statement to be executed with multiple sets of values. I don't see an easy way to express either of these with the DbBatch API so I might not end up supporting them through DbBatch.

[roji]

There's also a (separate) bulk insert command that allows one prepared insert statement to be executed with multiple sets of values. I don't see an easy way to express either of these with the DbBatch API so I might not end up supporting them through DbBatch.

@divega and I discussed this at some point, calling it "SIMD". In fact, IIRC JDBC's batching API (for prepared statements) allows only this - no way to send heterogeneous statements in a single roundtrip.

While "SIMD mode" may be a relatively common usage for batching, assuming prepared statements exist, there doesn't seem to be much extra value in it - one can simply execute the same prepared statement N times with different parameters within a single batch. How exactly that's exposed in a .NET API would be somewhat provider-specific; my expectation is that calling Prepare() on a batch would detect identical SQL and do the right thing.