The LastBatchProcessingThroughput JMX metric is currently computed using the batch's change count, which represents the inserts, updates, and deletes observed during the last batch window of data.

However, the issue is that this will often (particularly if scenarios where the batch may consist of more transaction markers and empty transactions than actual captured table DML events) be skewed to appear like the throughput is substantially lower than in whats actual because we are not taking into account all rows in the JDBC result set.

I propose that the JMX metric be changed to be based on the BatchMetrics JdbcRows calculation, which better represents the number of rows in the JDBC result set, including whether those rows were skipped, processed, or represent a transaction marker, DDL, or DML operation. This should make the throughput appear higher with a more accurate numerator value.