What

Bounds the work R2DBC does to name a Batch span. The resource is now built from the batch's first 10 statements, as their distinct normalized forms, instead of normalizing all statements joined together.

Why

Fixes #12932. A Batch reaches TraceProxyExecutionListener.beforeQuery once with all its statements, on the thread executing the query (usually an I/O event loop). The listener joined them with "; " and normalized the result. SQLNormalizer.normalize copies the rest of the buffer for each literal it replaces, so its cost grows quadratically with input size. A batch of thousands of distinct INSERTs with inlined values kept the event loop busy for tens of seconds.

Measured with SQLNormalizer.normalize on joined batches of ~280-character INSERT statements:

After this change a batch costs at most 10 single-statement normalizations (~16 µs each), whatever its size.

Behavior change

• Same-template batches get that one template as their resource. For example, 10,000 inlined-value inserts produce INSERT INTO t (id, name) VALUES (?, ?). Before, the resource was every normalized statement joined together.
• Mixed batches list their distinct templates in order, joined with ; , taken from the first 10 statements.
• Batch entries use DBQueryInfo.ofStatement, so statements with distinct inlined literals don't fill the prepared-statement cache.
• Single statements are unchanged.

Testing

• R2dbcInstrumentationTest:
  • A 10,000-statement batch with distinct values produces one span with the single normalized INSERT resource. This test fails on master, where the resource is the whole joined batch.
  • A mixed INSERT/UPDATE/DELETE batch lists the distinct templates in order.
• check, muzzle, latestDepTest: all pass.

SQLNormalizer itself is still quadratic on very large inputs, which also affects JDBC. That is left for a separate change.

🤖 Generated with Claude Code