Add query batching #180
Draft
Add query batching #180
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BenchmarkResultsCurrent status |
marco6
force-pushed
the
KU-1744/batching
branch
from
9c528c7 to
c5319ec
Compare
|
Depends on #181 |
marco6
force-pushed
the
KU-1744/batching
branch
2 times, most recently
from
2d6889f to
bd5b970
Compare
|
Ready as #181 was merged. |
There was a problem hiding this comment.
Great work @marco6, took a first look.
I would like to understand why we have some outliers in our benchmark test, some being as high as +900% through our change. Overall, the benchmark is looking very promising.
marco6
force-pushed
the
KU-1744/batching
branch
from
ba4887f to
bd5b970
Compare
|
Heads up for any reviewer: I moved the logic in a separate package, together with the old |
marco6
force-pushed
the
KU-1744/batching
branch
2 times, most recently
from
f93f082 to
907ce6c
Compare
|
This PR has been rebased so that the benchmarks results are comparing the current master branch. |
Draft
louiseschmidtgen
requested review from
a team
and removed request for
TheSignPainter98
|
Given the increased memory requirement from this PR, I think we should wait canonical/dqlite#714. |
marco6
force-pushed
the
KU-1744/batching
branch
from
f11a99e to
4e16cd4
Compare
Merged
marco6
force-pushed
the
KU-1744/batching
branch
from
4e16cd4 to
ecafe37
Compare
|
This PR now depends also on #216 which factors out all the code which is not related to batching from this PR. Some of the comments here are in fact about the refactor rather than batching itself and should be probably discussed there. |
marco6
force-pushed
the
KU-1744/batching
branch
from
ecafe37 to
54d1b5b
Compare
|
I have rebased this on top of master as #216 was merged. The patch now is way smaller. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All update operations (insert/update/delete) force a fsync on the WAL (and sometimes on the disk because of checkpoints). This limits the number of operations to what the underlying disk can do (usually in the order of hundreds).
Grouping these operations in transactions should dramatically increase the throughput while making the top X%ile latency a bit higher. However, this should be balanced by a lower latency in the bottom X%ile.
We should test this also on a real cluster.
This PR also removes the write lock as now there is always only one active writer.