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

On Sat, Apr 01, 2023 at 01:29:13PM -0400, Melanie Plageman wrote:
> Hi,
>
> I was just doing some cleanup on the main patch in this set and realized
> that it was missing a few things. One of which is forbidding the
> BUFFER_USAGE_LIMIT with VACUUM FULL since VACUUM FULL does not use a
> BAS_VACUUM strategy.
>
> VACUUM FULL technically uses a bulkread buffer access strategy for
> reading the original relation if its number of blocks is > number of
> shared buffers / 4 (see initscan()). The new rel writing is done using
> smgrextend/write directly and doesn't go through shared buffers. I
> think it is a stretch to try and use the size passed in to VACUUM by
> BUFFER_USAGE_LIMIT for the bulkread strategy ring.

When you say that it's a stretch, do you mean that it'd be a pain to add
arguments to handful of functions to pass down the setting ? Or that
it's unclear if doing so would be the desirable/needed/intended/expected
behavior ?

I think if VACUUM FULL were going to allow a configurable strategy size,
then so should CLUSTER. But it seems fine if they don't.

I wonder if maybe strategy should be configurable in some more generic
way, like a GUC. At one point I had a patch to allow INSERT to use
strategy buffers (not just INSERT SELECT). And that's still pretty
desirable. Also COPY. I've seen load spikes caused by pg_dumping
tables which are just below 25% of shared_buffers. Which is exacerbated
because pg_dump deliberately orders tables by size, so those tables are
dumped one after another, each causing eviction of ~20% of shared
buffers. And exacerbated some more because TOAST don't seem to use a
ring buffer in that case.

> I somehow feel like VACUUM (FULL, BUFFER_USAGE_LIMIT 'x') should error
> out instead of silently not using the buffer usage limit, though.
>
> I am looking for others' opinions.

Sorry, no opinion here :)

One thing is that it's fine to take something that previously throw an
error and change it to not throw an error anymore. But it's undesirable
to do the opposite. For that reason, there's may be a tendency to add
errors for cases like this.

--
Justin