On Wed, Feb 12, 2025 at 3:22 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2025-02-12 13:59:21 +1300, Thomas Munro wrote:
> > How about just maintaining it in a new variable
> > effective_io_combine_limit, whenever either of them is assigned?
>
> Yea, that's probably the least bad way.
>
> I wonder if we should just name that variable io_combine_limit and have the
> GUC be _raw or _guc or such? There's gonna be a fair number of references to
> the variable in code...
Alternatively, we could compute that as stream->io_combine_limit and
use that. That has the advantage that it's fixed for the life of the
stream, even if you change it (eg between fetches from a CURSOR that
has streams). Pretty sure it won't break anything today, but it might
just run out of queue space limiting concurrency arbitrarily if you
increase it, which is a bit weird now that I focus on that. Capturing
the value we'll use up front seems better on that front. On the other
hand, other future code might also have to remember to compute that
too (write streams, ...), a tiny bit of duplication. Something like
the attached. Or ... I guess we could do both things?