Not to be confused with #2156, which is about evaluating parts of a single query simultaneously.
The JavaScript driver and many community drivers are asynchronous, but they don't get the full benefit of it because the server will only evaluate one query at a time on a single connection.
This also causes pathological behaviour when using changefeeds. Each changefeed adds a possible latency of 500ms to all other queries on the same connection. The only sane way to use changefeeds is to open a new connection for each changefeed. I believe this problem would be better solved by allowing parallel execution of queries on a single connection and not by adding server pools.
Another disadvantage of the current situation is that listening on an empty changefeed will cause an empty response to be sent every 500ms. This causes useless wake-ups and network traffic.
With this proposal, if a user waits for the result of a query before sending the next query to the server, queries would still be executed sequentially.
When this is implemented, we should include a backwards-compatible mode. Some drivers rely on the fact that responses are in the same order as their respective requests.
To avoid complications in the web UI, it may be easier to not make this change for HTTP connections.
This proposal is based on my understanding of the current behaviour, please correct me if I am wrong.
@mlucy @danielmewes Any thoughts?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4