diff options
author | Thomas Munro <tmunro@postgresql.org> | 2025-03-19 15:23:12 +1300 |
---|---|---|
committer | Thomas Munro <tmunro@postgresql.org> | 2025-03-19 15:40:35 +1300 |
commit | 06fb5612c970b3af95aca3db5a955669b07537ca (patch) | |
tree | a3cfb560033bfd70e68f72e8d58ddc99250f5afb /src/backend/executor/execUtils.c | |
parent | 10f6646847515b1ab02735c24b04abaf1996f65f (diff) | |
download | postgresql-06fb5612c970b3af95aca3db5a955669b07537ca.tar.gz postgresql-06fb5612c970b3af95aca3db5a955669b07537ca.zip |
Increase io_combine_limit range to 1MB.
The default of 128kB is unchanged, but the upper limit is changed from
32 blocks to 128 blocks, unless the operating system's IOV_MAX is too
low. Some other RDBMSes seem to cap their multi-block buffer pool I/O
around this number, and it seems useful to allow experimentation.
The concrete change is to our definition of PG_IOV_MAX, which provides
the maximum for io_combine_limit and io_max_combine_limit. It also
affects a couple of other places that work with arrays of struct iovec
or smaller objects on the stack, so we still don't want to use the
system IOV_MAX directly without a clamp: it is not under our control and
likely to be 1024. 128 seems acceptable for our current usage.
For Windows, we can't use real scatter/gather yet, so we continue to
define our own IOV_MAX value of 16 and emulate preadv()/pwritev() with
loops. Someone would need to research the trade-offs of raising that
number.
NB if trying to see this working: you might temporarily need to hack
BAS_BULKREAD to be bigger, since otherwise the obvious way of "a very
big SELECT" is limited by that for now.
Suggested-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CA%2BhUKG%2B2T9p-%2BzM6Eeou-RAJjTML6eit1qn26f9twznX59qtCA%40mail.gmail.com
Diffstat (limited to 'src/backend/executor/execUtils.c')
0 files changed, 0 insertions, 0 deletions