Grouping unrelated statements in an NpgsqlBatch today seems to work but it has some serious pitfalls. An NpgsqlBatch writes just one sync following all statements and this has a large impact on transactionality (all statements share a transaction) and error handling (later statements get aborted). Giving users the flexibility to group unrelated statements in a way similar to batching seems useful enough as there are some obvious and less obvious advantages to this:
- Fresh transaction per statement
- Postgres errors would be contained to the offending statement, continuing executing the remaining statements.
- Controlling scheduling for unrelated queries in multiplexing becomes easier. By grouping them there is a guarantee of sequential enqueue of the entire batch onto a single connection. This results in straight line execution and results, improving locality (by trading it off against parallelization gains when other connections are idle).
This would likely be some switch on NpgsqlBatch causing a sync to get written after each statement in that batch.
@roji astutely mentioned that dealing with errors will be more complicated. Would we delay any errors and throw these at their respective NextResult call?
Grouping unrelated statements in an NpgsqlBatch today seems to work but it has some serious pitfalls. An NpgsqlBatch writes just one sync following all statements and this has a large impact on transactionality (all statements share a transaction) and error handling (later statements get aborted). Giving users the flexibility to group unrelated statements in a way similar to batching seems useful enough as there are some obvious and less obvious advantages to this:
This would likely be some switch on NpgsqlBatch causing a sync to get written after each statement in that batch.
@roji astutely mentioned that dealing with errors will be more complicated. Would we delay any errors and throw these at their respective NextResult call?