-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pipeline mode #75
Labels
Comments
This was referenced May 13, 2022
Closed
MariaDB has a bulk execution interface that may be relevant here: https://mariadb.com/kb/en/com_stmt_bulk_execute/ |
This was referenced Apr 23, 2024
Closed
anarthal
added a commit
that referenced
this issue
May 10, 2024
Fixed a potential ODR violation with `asio::coroutine` under MSVC, manifesting as sporadic test failures under release configurations. `any_stream` has been replaced by the internal `EngineStream` concept and the `engine` interface. `algo_runner` has been replaced by `top_level_algo`, improving algorithm type-erasing This change is required by #195 and beneficial for #75 close #259
This was referenced Jun 3, 2024
Merged
anarthal
added a commit
that referenced
this issue
Jun 8, 2024
Removed sansio_algorithm base class close #75
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Implement client-side pipelining of requests.
When executing a text query or a prepared statement, the following packet exchange occurs:
Currently,
connection::query
orprepared_statement::execute
write the query request, read the OK and the metadata. Then the client needs to read all the rows until the EOF before executing another query request.It is possible to write several of these query requests at once, in batch. Doing this, we can save round-trips. Subsequent queries won't wait until a response has been written. Note that there is no special support for this neither in the protocol nor in the server. The server will process the queries sequentially, as if they had been written one by one. If one of the queries fail, subsequent queries will be executed, regardless of the result of previous queries.
This would be the message exchange:
The client would still need to read the resultset yielded by query 1 completely before starting with query 2 resultset.
Implementing this pipeline mode requires an additional, lower level interface. A possible implementation for requests is a
serializer
object with methods such asadd_query
andadd_statement_execution
that implements request serialization, then aconnection::write(serializer)
method. To read responses, we can implement methods such asconnection::read_resultset_metadata(resultset&)
andconnection::read_row(resultset&, row&)
.The text was updated successfully, but these errors were encountered: