public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jim Nasby <[email protected]>
To: Masahiko Sawada <[email protected]>
To: Melanie Plageman <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Andres Freund <[email protected]>
Subject: Re: Should vacuum process config file reload more often
Date: Wed, 8 Mar 2023 11:42:31 -0600
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAD21AoB=EC6wzjjqDXKmNEhu_BhGg0g_Gc50yh_zvXqiDC_OSg@mail.gmail.com>
References: <CAAKRu_ZngzqnEODc7LmS1NH04Kt6Y9huSjz5pp7+DXhrjDA0gw@mail.gmail.com>
<CAD21AoC=b09pzWNyPYuti0M2DQwy57CGF9UWWb_+v=gdWeNG=A@mail.gmail.com>
<CAAKRu_bR2VrTUskR24GkXV15SxPaCiHYD=soOuWZcT-rGDcA8Q@mail.gmail.com>
<CAD21AoB=EC6wzjjqDXKmNEhu_BhGg0g_Gc50yh_zvXqiDC_OSg@mail.gmail.com>
On 3/2/23 1:36 AM, Masahiko Sawada wrote:
>>>> For example, I guess we will need to take care of changes of
>>>> maintenance_work_mem. Currently we initialize the dead tuple space at
>>>> the beginning of lazy vacuum, but perhaps we would need to
>>>> enlarge/shrink it based on the new value?
Doesn't the dead tuple space grow as needed? Last I looked we don't
allocate up to 1GB right off the bat.
>>> I don't think we need to do anything about that initially, just because the
>>> config can be changed in a more granular way, doesn't mean we have to react to
>>> every change for the current operation.
>> Perhaps we can mention in the docs that a change to maintenance_work_mem
>> will not take effect in the middle of vacuuming a table. But, Ithink it probably
>> isn't needed.
> Agreed.
I disagree that there's no need for this. Sure, if
maintenance_work_memory is 10MB then it's no big deal to just abandon
your current vacuum and start a new one, but the index vacuuming phase
with maintenance_work_mem set to say 500MB can take quite a while.
Forcing a user to either suck it up or throw everything in the phase
away isn't terribly good.
Of course, if the patch that eliminates the 1GB vacuum limit gets
committed the situation will be even worse.
While it'd be nice to also honor maintenance_work_mem getting set lower,
I don't see any need to go through heroics to accomplish that. Simply
recording the change and honoring it for future attempts to grow the
memory and on future passes through the heap would be plenty.
All that said, don't let these suggestions get in the way of committing
this. Just having the ability to tweak cost parameters would be a win.
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Should vacuum process config file reload more often
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox