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

I've now pushed up v8-0004. Can rebase the remaining 2 patches on top
of master again and resend?

On Mon, 3 Apr 2023 at 08:11, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
> I still have a few open questions:
> - what the initial value of ring_size for autovacuum should be (see the
> one remaining TODO in the code)

I assume you're talking about the 256KB BAS_VACUUM one set in
GetAccessStrategy()? I don't think this patch should be doing anything
to change those defaults. Anything that does that should likely have
a new thread and come with analysis or reasoning about why the newly
proposed defaults are better than the old ones.

> - should ANALYZE allow specifying BUFFER_USAGE_LIMIT since it uses the guc
> value when that is set?

That's a good question...

> - should INDEX_CLEANUP off cause VACUUM to use shared buffers and
> disable use of a strategy (like failsafe vacuum)

I don't see why it should. It seems strange to have one option
magically make changes to some other option.

> - should we add anything to VACUUM VERBOSE output about the number of
> reuses of strategy buffers?

Sounds like this would require an extra array of counter variables in
BufferAccessStrategyData? I think it might be a bit late to start
experimenting with this.

> - Should we make BufferAccessStrategyData non-opaque so that we don't
> have to add a getter for nbuffers. I could have implemented this in
> another way, but I don't really see why BufferAccessStrategyData
> should be opaque

If nothing outside of the .c file requires access then there's little
need to make the members known outside of the file. Same as you'd want
to make classes private rather than public when possible in OOP.

If you do come up with a reason to be able to determine the size of
the BufferAccessStrategy from outside freelist.c, I'd say an accessor
method is the best way.

David

David