On Wed, Jan 11, 2023 at 2:39 PM Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2023-01-11 16:18:34 -0500, Tom Lane wrote: > > Peter Geoghegan <p...@bowt.ie> writes: > > > On Wed, Jan 11, 2023 at 11:18 AM Andres Freund <and...@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. David J.
