On Tue, 22 Nov 2022 at 16:43, Justin Pryzby <pry...@telsasoft.com> wrote: > > On Mon, Nov 21, 2022 at 03:07:25PM +0000, Simon Riggs wrote: > > Attached patch implements VACUUM (BACKGROUND). > > > > There are quite a few small details to consider; please read the docs > > and comments. > > > > There is a noticeable delay before the background vacuum starts. > > You disallowed some combinations of unsupported options, but not others, > like FULL, PARALLEL, etc. They should either be supported or > prohibited. > > + /* use default values */ > + tab.at_params.log_min_duration = 0; > > 0 isn't the default ? > > Maybe VERBOSE should mean to set min_duration=0, otherwise it should use > the default ?
+1 > You only handle one rel, but ExecVacuum() has a loop around rels. > > +NOTICE: autovacuum of "vactst" has been requested, using the options > specified > > => I don't think it's useful to say "using the options specified". > > Should autovacuum de-duplicate requests ? > BRIN doesn't do that, but it's intended for append-only tables, so the > issue doesn't really come up. Easy to do > Could add psql tab-completion. > > Is it going to be confusing that the session's GUC variables won't be > transmitted to autovacuum ? For example, the freeze and costing > parameters. I think we should start with the "how do I want it to behave" parts of the above and leave spelling and tab completion as final items. Other questions are whether there should be a limit on number of background vacuums submitted at any time. Whether there should be a GUC that specifies the max number of queued tasks. Do we need a query that shows what items are queued? etc Justin, if you wanted to take up the patch from here, I would be more than happy. You have the knowledge and insight to make this work right. We should probably start a new CF patch entry so we can return the original patch as rejected, then continue with this new idea separately. -- Simon Riggs http://www.EnterpriseDB.com/