Remove arbitrary cap on read_stream.c buffer queue.
authorThomas Munro <tmunro@postgresql.org>
Thu, 27 Feb 2025 01:15:15 +0000 (14:15 +1300)
committerThomas Munro <tmunro@postgresql.org>
Thu, 27 Feb 2025 07:49:48 +0000 (20:49 +1300)
commit55918f798bc2d1846eea0d805fbec91d4e1816e0
tree3fcb4c7c20fcaaaced7feb3cfa34fabe2b6da26d
parent48e4ae9a0707b22cf874a4e8e531a07077318424
Remove arbitrary cap on read_stream.c buffer queue.

Previously the internal queue of buffers was capped at max_ios * 4,
though not less than io_combine_limit, at allocation time.  That was
done in the first version based on conservative theories about resource
usage and heuristics pending later work.  The configured I/O depth could
not always be reached with dense random streams generated by ANALYZE,
VACUUM, the proposed Bitmap Heap Scan patch, and also sequential streams
with the proposed AIO subsystem to name some examples.

The new formula is (max_ios + 1) * io_combine_limit, enough buffers for
the full configured I/O concurrency level using the full configured I/O
combine size, plus the buffers from one finished but not yet consumed
full-sized I/O.  Significantly more memory would be needed for high GUC
values if the client code requests a large per-buffer data size, but
that is discouraged (existing and proposed stream users try to keep it
under a few words, if not zero).

With this new formula, an intermediate variable could have overflowed
under maximum GUC values, so its data type is adjusted to cope.

Discussion: https://postgr.es/m/CA%2BhUKGK_%3D4CVmMHvsHjOVrK6t4F%3DLBpFzsrr3R%2BaJYN8kcTfWg%40mail.gmail.com
src/backend/storage/aio/read_stream.c