Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Ants Aasma <ants@cybertec.at>
From: Ants Aasma <ants@cybertec.at>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Date: 2023-03-13T12:37:51Z
Lists: pgsql-hackers
On Sat, 11 Mar 2023 at 16:55, Melanie Plageman <melanieplageman@gmail.com> wrote: > > > On Tue, Feb 28, 2023 at 3:16 AM Bharath Rupireddy > > <bharath.rupireddyforpostgres@gmail.com> wrote: > > > > > On Thu, Jan 12, 2023 at 6:06 AM Andres Freund <andres@anarazel.de> wrote: > > > > > > > > On 2023-01-11 17:26:19 -0700, David G. Johnston wrote: > > > > > Should we just add "ring_buffers" to the existing "shared_buffers" and > > > > > "temp_buffers" settings? > > > > > > > > The different types of ring buffers have different sizes, for good reasons. So > > > > I don't see that working well. I also think it'd be more often useful to > > > > control this on a statement basis - if you have a parallel import tool that > > > > starts NCPU COPYs you'd want a smaller buffer than a single threaded COPY. Of > > > > course each session can change the ring buffer settings, but still. > > > > > > How about having GUCs for each ring buffer (bulk_read_ring_buffers, > > > bulk_write_ring_buffers, vacuum_ring_buffers - ah, 3 more new GUCs)? > > > These options can help especially when statement level controls aren't > > > easy to add (COPY, CREATE TABLE AS/CTAS, REFRESH MAT VIEW/RMV)? If > > > needed users can also set them at the system level. For instance, one > > > can set bulk_write_ring_buffers to other than 16MB or -1 to disable > > > the ring buffer to use shared_buffers and run a bunch of bulk write > > > queries. > > In attached v3, I've changed the name of the guc from buffer_usage_limit > to vacuum_buffer_usage_limit, since it is only used for vacuum and > autovacuum. Sorry for arriving late to this thread, but what about sizing the ring dynamically? From what I gather the primary motivation for larger ring size is avoiding WAL flushes due to dirty buffer writes. We already catch that event with StrategyRejectBuffer(). So maybe a dynamic sizing algorithm could be applied to the ringbuffer. Make the buffers array in strategy capable of holding up to the limit of buffers, but set ring size conservatively. If we have to flush WAL, double the ring size (up to the limit). If we loop around the ring without flushing, decrease the ring size by a small amount to let clock sweep reclaim them for use by other backends. -- Ants Aasma Senior Database Engineer www.cybertec-postgresql.com
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