doc: Improve description of io_combine_limit and io_max_combine_limit GUCs

From: Karina Litskevich <litskevichkarina(at)gmail(dot)com>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs
Date: 2025-10-08 11:38:20
Message-ID: CACiT8iZCDkz1bNYQNQyvGhXWJExSnJULRTYT894u4-Ti7Yh6jw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

I noticed that GUCs io_combine_limit and io_max_combine_limit are marked
as GUC_UNIT_BLOCKS, but in the documentation nothing is said about that.
Other GUCs marked as GUC_UNIT_BLOCKS have a phrase "If this value is
specified without units, it is taken as blocks, that is BLCKSZ bytes,
typically 8kB" in their descriptions in the documentation. Please find
the attached patch that adds the same phrase for io_combine_limit and
io_max_combine_limit. This will need backpatching: io_combine_limit has
been present since PostgreSQL 17, and io_max_combine_limit since
PostgreSQL 18.

I also have a question about the main part of the description of these
GUCs. It says, "Controls the largest I/O size in operations that combine
I/O." From what I can see, these GUCs really only affect read operations,
and this description looks misleading to me. Am I wrong?

Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/

Attachment Content-Type Size
v1-0001-doc-Improve-description-of-io_combine_limit-and-i.patch text/x-patch 1.5 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-10-08 11:42:31 Re: Resetting recovery target parameters in pg_createsubscriber
Previous Message Álvaro Herrera 2025-10-08 11:36:14 Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended