On Wed, Jan 11, 2023 at 2:39 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2023-01-11 16:18:34 -0500, Tom Lane wrote: > Peter Geoghegan <pg@bowt.ie> writes: > > On Wed, Jan 11, 2023 at 11:18 AM Andres Freund <andres@anarazel.de> wrote: > >> I don't like that - it's also quite useful to disable use of ringbuffers when > >> you actually need to clean up indexes. Especially when we have a lot of dead > >> tuples we'll rescan indexes over and over... > > > That's a fair point. > > > My vote goes to "REUSE_BUFFERS", then. > > I wonder whether it could make sense to allow a larger ringbuffer size, > rather than just the limit cases of "on" and "off".
I can see that making sense, particularly if we were to later extend this to other users of ringbuffers. E.g. COPYs us of the ringbuffer makes loading of data > 16MB but also << s_b vastly slower, but it can still be very important to use if there's lots of parallel processes loading data.
Should we just add "ring_buffers" to the existing "shared_buffers" and "temp_buffers" settings?
Then give VACUUM a (BUFFER_POOL=ring*|shared) option?
I think making DBAs aware of this dynamic and making the ring buffer usage user-facing is beneficial in its own right (at least, the concept that changes done by vacuum don't impact shared_buffers, regardless of how that non-impact manifests). But I don't see much benefit trying to come up with a different name.
