Hi, On 2026-04-16 16:21:35 -0400, Melanie Plageman wrote: > On Sun, Apr 5, 2026 at 11:49 AM Andres Freund <[email protected]> wrote: > > > > I think we should probably just have GetLocalPinLimit() return something > > considerably smaller than num_temp_buffers, e.g. num_temp_buffers / 4 or > > so. > > I think num_temp_buffers / 4 seems reasonable for GetLocalPinLimit(). > We'd also need to make this change in GetAdditionalLocalPinLimit().
Right. > We will likely see an impact on performance impact because this will > keep the readahead distance substantially lower for temp table cases > with only one read stream. I don't think it's likely to be practically relevant. Unless you use a toy sized temp_buffers - in which case readahead won't be a relevant performance bottleneck - the pinned limit will often even be higher than with shared buffers (due to the shared buffers pin limit being divided by MaxBackends). Even at the default temp_buffers=1024/8MB, the limit would be 256. That's quite high for a single scan in such a tiny pool. > > There always may be more than one scan going on, so we can't ever promise > > that > > there's at least a certain number of pins available. The main goal of the > > shared pin limit is to prevent one backend from pinning disproportionally > > much > > of s_b. And for that eventually scaling down to just needing 1-2 pins per > > scan is sufficient. > > With the last sentence "And for that eventually scaling down to just > needing 1-2 pins per scan is sufficient." -- how do you mean to relate > that to what we will do with local buffers case? Just explaining why we shouldn't see these limits as hard limits that may never be exceeded, but as caps that make problems less likely. I guess I could see an argument for doing something more complicated for temp buffers than num_temp_buffers / 4, e.g. Min(1, (num_temp_buffers - NLocalPinnedBuffers) / 4) so that we get more conservative the more scans are concurrently in progress. But I'd not go there right now, that seems like a more complicated project (and we'd presumably want to do something roughly similar for the s_b case). Greetings, Andres Freund
