Feedback-ID: id4a34324:Fastmail
Date: Wed, 8 Mar 2023 16:27:29 -0800
From: Andres Freund <andres@anarazel.de>
To: Jim Nasby <nasbyj@amazon.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
	Melanie Plageman <melanieplageman@gmail.com>,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Should vacuum process config file reload more often
Message-ID: <20230309002729.6ugxojaw22xowa4u@awork3.anarazel.de>
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>
 <7121ac43-d6ae-33ca-8ddc-538b0c6ab492@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7121ac43-d6ae-33ca-8ddc-538b0c6ab492@amazon.com>
Archived-At: <https://www.postgresql.org/message-id/20230309002729.6ugxojaw22xowa4u%40awork3.anarazel.de>
Precedence: bulk

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