Hi,
On 2023-03-08 11:42:31 -0600, Jim Nasby wrote:
> 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.
Nobody said anything about it not being useful to react to m_w_m changes, just
that it's not required to make some progress . So I really don't understand
what the point of your comment is.
Greetings,
Andres Freund
