batch queries to maximize throughput
query-side streams for first level of callsites Signed-off-by: Jason Volk <jason@zemos.net>
This commit is contained in:
parent
1792711d09
commit
2259e2c82f
13 changed files with 191 additions and 56 deletions
|
@ -1457,6 +1457,19 @@
|
|||
#
|
||||
#stream_width_scale = 1.0
|
||||
|
||||
# Sets the initial amplification factor. This controls batch sizes of
|
||||
# requests made by each pool worker, multiplying the throughput of each
|
||||
# stream. This value is somewhat abstract from specific hardware
|
||||
# characteristics and can be significantly larger than any thread count or
|
||||
# queue size. This is because each database query may require several
|
||||
# index lookups, thus many database queries in a batch may make progress
|
||||
# independently while also sharing index and data blocks which may or may
|
||||
# not be cached. It is worthwhile to submit huge batches to reduce
|
||||
# complexity. The maximum value is 32768, though sufficient hardware is
|
||||
# still advised for that.
|
||||
#
|
||||
#stream_amplification = 1024
|
||||
|
||||
# Number of sender task workers; determines sender parallelism. Default is
|
||||
# '0' which means the value is determined internally, likely matching the
|
||||
# number of tokio worker-threads or number of cores, etc. Override by
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue