Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2023-04-05T17:05:53Z
Lists: pgsql-hackers
Hi,
On 2023-04-04 13:53:15 -0400, Melanie Plageman wrote:
> > 8. I don't quite follow this comment:
> >
> > /*
> > * TODO: should this be 0 so that we are sure that vacuum() never
> > * allocates a new bstrategy for us, even if we pass in NULL for that
> > * parameter? maybe could change how failsafe NULLs out bstrategy if
> > * so?
> > */
> >
> > Can you explain under what circumstances would vacuum() allocate a
> > bstrategy when do_autovacuum() would not? Is this a case of a config
> > reload where someone changes vacuum_buffer_usage_limit from 0 to
> > something non-zero? If so, perhaps do_autovacuum() needs to detect
> > this and allocate a strategy rather than having vacuum() do it once
> > per table (wastefully).
Hm. I don't much like that we use a single strategy for multiple tables
today. That way even tiny tables never end up in shared_buffers. But that's
really a discussion for a different thread. However, if were to use a
per-table bstrategy, it'd be a lot easier to react to changes of the config.
I doubt it's worth adding complications to the code for changing the size of
the ringbuffer during an ongoing vacuum scan, at least for 16. Reacting to
enabling/disbling the ringbuffer alltogether seems a bit more important, but
still not crucial compared to making it configurable at all.
I think it'd be OK to add a comment saying something like "XXX: In the future
we might want to react to configuration changes of the ring buffer size during
a vacuum" or such.
WRT to the TODO specifically: Yes, passing in 0 seems to make sense. I don't
see a reason not to do so? But perhaps there's a better solution:
Perhaps the best solution for autovac vs interactive vacuum issue would be to
move the allocation of the bstrategy to ExecVacuum()?
Random note while looking at the code:
ISTM that adding handling of -1 in GetAccessStrategyWithSize() would make the
code more readable. Instead of
if (params->ring_size == -1)
{
if (VacuumBufferUsageLimit == -1)
bstrategy = GetAccessStrategy(BAS_VACUUM);
else
bstrategy = GetAccessStrategyWithSize(BAS_VACUUM, VacuumBufferUsageLimit);
}
else
bstrategy = GetAccessStrategyWithSize(BAS_VACUUM, params->ring_size);
you could just have something like:
bstrategy = GetAccessStrategyWithSize(BAS_VACUUM,
params->ring_size != -1 ? params->ring_size : VacuumBufferUsageLimit);
by falling back to the default values from GetAccessStrategy().
Or even more "extremely", you could entirely remove references to
VacuumBufferUsageLimit and handle that in freelist.c
Greetings,
Andres Freund
Commits
-
Add unit to vacuum_buffer_usage_limit value in postgresql.conf.sample.
- b72f564d87d1 16.0 landed
-
Improve VACUUM/ANALYZE BUFFER_USAGE_LIMIT docs
- c0235013c13b 16.0 landed
-
Add --buffer-usage-limit option to vacuumdb
- ae78cae3be62 16.0 landed
-
Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option
- 1cbbee033857 16.0 landed
-
Move various prechecks from vacuum() into ExecVacuum()
- b9b125b9c143 16.0 landed
-
Always make a BufferAccessStrategy for ANALYZE
- bccd6908ca82 16.0 landed
-
Rename BufferAccessStrategyData.ring_size to nbuffers
- 8d928e3a9fe7 16.0 landed
-
Disable vacuum's use of a buffer access strategy during failsafe
- 4830f1024325 16.0 landed
-
Only make buffer strategy for vacuum when it's likely needed
- 32fbe0239b03 16.0 landed
-
Remove some global variables from vacuum.c
- 3f476c953495 16.0 landed
-
Doc: add Buffer Access Strategy to the glossary
- c8f8d0eb1868 16.0 landed