From: | Thomas Munro <tmunro(at)postgresql(dot)org> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Remove arbitrary cap on read_stream.c buffer queue. |
Date: | 2025-02-27 07:51:28 |
Message-ID: | E1tnYg3-000JQb-1a@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/55918f798bc2d1846eea0d805fbec91d4e1816e0
Modified Files
--------------
src/backend/storage/aio/read_stream.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2025-02-27 09:28:01 | pgsql: Get rid of ojrelid local variable in remove_rel_from_query() |
Previous Message | Michael Paquier | 2025-02-27 05:06:57 | pgsql: pg_amcheck: Fix inconsistency in memory freeing |