Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode

From: Andres Freund <[email-masked]>
Date: Wed, 11 Jan 2023 10:58:54 -0800

Hi,

On 2023-01-11 10:35:19 -0800, Peter Geoghegan wrote:
> On Wed, Jan 11, 2023 at 10:27 AM Andres Freund <[email-masked]> wrote:
> > Therefore I'd like to add an option to the VACUUM command to use to disable
> > the use of the ringbuffer. Not sure about the name yet.
> 
> Sounds like a good idea.

Any idea about the name? The obvious thing is to reference ring buffers in the
option name, but that's more of an implementation detail...

Some ideas:

USE_RING_BUFFERS on|off
SCAN_PROTECTION on|off
REUSE_BUFFERS on|off
LIMIT_BUFFER_USAGE on|off

Regards,

Andres

---

From: Peter Geoghegan <[email-masked]>
Date: Wed, 11 Jan 2023 11:06:26 -0800

> option name, but that's more of an implementation detail...

What are the chances that anybody using this feature via a manual
VACUUM command will also use INDEX_CLEANUP off? It's not really
supposed to be used routinely, at all. Right? It's just for
emergencies.

Perhaps it can be tied to INDEX_CLEANUP=off? That makes it hard to get
just the behavior you want when testing VACUUM, but maybe that doesn't
matter.

Realistically, most of the value here comes from changing the failsafe
behavior, which doesn't require the user to know anything about
VACUUM. I know that AWS has reduced the vacuum_failsafe_age default on
RDS to 1.2 billion (a decision made before I joined Amazon), so it is
already something AWS lean on quite a bit where available.

-- 
Peter Geoghegan

---

From: Andres Freund <[email-masked]>
Date: Wed, 11 Jan 2023 11:18:42 -0800

Hi,

> supposed to be used routinely, at all. Right? It's just for

I think it's also quite useful for e.g. vacuuming after initial data loads or
if you need to do a first vacuum after a lot of bloat accumulated due to a
stuck transaction.

> just the behavior you want when testing VACUUM, but maybe that doesn't

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...

Greetings,

Andres Freund

---

From: Peter Geoghegan <[email-masked]>
Date: Wed, 11 Jan 2023 11:20:51 -0800

> tuples we'll rescan indexes over and over...

That's a fair point.

My vote goes to "REUSE_BUFFERS", then.

-- 
Peter Geoghegan

---

From: Justin Pryzby <[email-masked]>
Date: Wed, 11 Jan 2023 14:38:34 -0600

> option name, but that's more of an implementation detail...

+1 for either of these.

I don't think it's an issue to expose implementation details here.
Anyone who wants to change this will know about the implementation
details that they're changing, and it's better to refer to it by the
same/similar name and not by some other name that's hard to find.

BTW I can't see that the ring buffer is currently exposed in any
user-facing docs for COPY/ALTER/VACUUM/CREATE ?

-- 
Justin

---

From: Andres Freund <[email-masked]>
Date: Wed, 11 Jan 2023 13:09:42 -0800

Hi,

> On Wed, Jan 11, 2023 at 10:58:54AM -0800, Andres Freund wrote:

Then I'd go for REUSE_BUFFERS. What made you prefer it over
LIMIT_BUFFER_USAGE?

USE_BUFFER_ACCESS_STRATEGY would be a name tied to the implementation that's
not awful, I think..

> same/similar name and not by some other name that's hard to find.

A ringbuffer could refer to a lot of things other than something limiting
buffer usage, that's why I don't like it.

> user-facing docs for COPY/ALTER/VACUUM/CREATE ?

Yea, there's surprisingly little in the docs about it, given how much it
influences behaviour. It's mentioned in tablesample-method.sgml, but without
explanation - and it's a page documenting C API...

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Wed, 11 Jan 2023 16:18:34 -0500

> 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".

			regards, tom lane