On Wed, Jul 22, 2026 at 12:53 PM Jingtang Zhang <[email protected]> wrote: > > The stream calculates its pin limit and queue capacity when it is > created. It uses the original strategy. This patch deliberately changes > only buffer replacement for future reads; it does not resize the stream.
I just wanted to also address this point. It's true that when we stop using the strategy in failsafe mode we will not adjust max_pinned_buffers -- but we couldn't adjust that without the ability to resize the buffers array in the read stream. Adding the ability to change max_pinned_buffers during an ongoing read stream seems like overkill to me. And making the array size bigger than the strategy needs it to be in the off chance we will abandon the strategy also feels wrong. If we calculate the impact on readahead, with any non-toy shared_buffers value and the default io_combine_limit and maintenance_io_concurrency values, max_pinned_buffers is 272. With the buffer access strategy, it is 128. That's a 2x reduction which is non-negligible. However, I think the primary benefit of using shared buffers instead of the strategy is that we don't have to write data (and flush wal) to make space to read the next page to vacuum. The reduced readahead distance isn't the end of the world -- and I don't think the changes required to fix it are worth it. - Melanie
