Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
От | David Rowley |
---|---|
Тема | Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode |
Дата | |
Msg-id | CAApHDvo57+sYWx+nwM3DXM2m0S8f1XDruTURSWjdwOSRKu6s9Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode |
Список | pgsql-hackers |
On Thu, 6 Apr 2023 at 12:42, Melanie Plageman <melanieplageman@gmail.com> wrote: > Attached is a v12 of the whole vacuum_buffer_usage_limit patch set which > includes a commit to fix the bug in master and a commit to move relevant > code from vacuum() up into ExecVacuum(). I'm still playing catch up to the moving of the pre-checks from vacuum() to ExecVacuum(). I'm now wondering... Is it intended that VACUUM t1,t2; now share the same strategy? Currently, in master, we'll allocate a new strategy for t2 after vacuuming t1. Does this not mean we'll now leave fewer t1 pages in shared_buffers because the reuse of the strategy will force them out with t2 pages? I understand there's nothing particularly invalid about that, but it is a change in behaviour that the patch seems to be making with very little consideration as to if it's better or worse. David
В списке pgsql-hackers по дате отправления: