On Mon, Aug 18, 2025 at 1:31 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
>
> On Fri, Aug 15, 2025 at 3:41 AM Masahiko Sawada wrote:
> >
>
> > 2. when an autovacuum worker (not parallel vacuum worker) who uses
> > parallel vacuum gets SIGHUP, it errors out with the error message
> > "paramete
Hi,
Thank you very much for your comments!
In this letter I'll answer both of your recent letters.
On Fri, Aug 8, 2025 at 6:38 AM Masahiko Sawada wrote:
>
> Thank you for updating the patch. Here are some review comments.
>
> +/* Release all launched (i.e. reserved) parallel autovacuum wo
On Thu, Aug 7, 2025 at 4:38 PM Masahiko Sawada wrote:
>
> On Mon, Jul 21, 2025 at 11:45 PM Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Mon, Jul 21, 2025 at 11:40 PM Sami Imseih wrote:
> > >
> > > I have only reviewed the v8-0001-Parallel-index-autovacuum.patch so far
> >
On Mon, Jul 21, 2025 at 11:45 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Mon, Jul 21, 2025 at 11:40 PM Sami Imseih wrote:
> >
> > I have only reviewed the v8-0001-Parallel-index-autovacuum.patch so far and
> > have a few comments from my initial pass.
> >
> > 1/ Please run pgin
Hi,
On Mon, Jul 21, 2025 at 11:40 PM Sami Imseih wrote:
>
> I have only reviewed the v8-0001-Parallel-index-autovacuum.patch so far and
> have a few comments from my initial pass.
>
> 1/ Please run pgindent.
OK, I'll do it.
> 2/ Documentation is missing. There may be more, but here are the plac
Thanks for the patches!
I have only reviewed the v8-0001-Parallel-index-autovacuum.patch so far and
have a few comments from my initial pass.
1/ Please run pgindent.
2/ Documentation is missing. There may be more, but here are the places I
found that likely need updates for the new behavior, rel
Hi,
On Fri, Jul 18, 2025 at 2:43 AM Masahiko Sawada wrote:
>
> On Mon, Jul 14, 2025 at 3:49 AM Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > This log level is used only "for messages about parallel workers launched".
> > I think that such logs relate more to the parallel workers module tha
On Mon, Jul 14, 2025 at 3:49 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
>
> > ---
> > + nlaunched_workers = pvs->pcxt->nworkers_launched; /* remember this
> > value */
> > DestroyParallelContext(pvs->pcxt);
> > +
> > + /* Release all launched (i.e. reserved) parallel autovacuum work
Hi,
On Mon, Jul 14, 2025 at 2:10 PM Masahiko Sawada wrote:
>
> ---
> - shared->maintenance_work_mem_worker =
> - (nindexes_mwm > 0) ?
> - maintenance_work_mem / Min(parallel_workers, nindexes_mwm) :
> - maintenance_work_mem;
> +
> + if (AmAutoVacuumWorkerProcess())
> +
On Sun, Jul 6, 2025 at 5:00 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Fri, Jul 4, 2025 at 9:21 PM Matheus Alcantara
> wrote:
> >
> > The "autovacuum_max_parallel_workers" declared on guc_tables.c mention
> > that is capped by "max_worker_process":
> > + {
> > +
Hi,
On Tue, Jul 8, 2025 at 10:20 PM Matheus Alcantara
wrote:
>
> On Sun Jul 6, 2025 at 5:00 AM -03, Daniil Davydov wrote:
> > I will keep the 'max_worker_processes' limit, so autovacuum will not
> > waste time initializing a parallel context if there is no chance that
> > the request will succeed
On Sun Jul 6, 2025 at 5:00 AM -03, Daniil Davydov wrote:
>> The "autovacuum_max_parallel_workers" declared on guc_tables.c mention
>> that is capped by "max_worker_process":
>> + {
>> + {"autovacuum_max_parallel_workers", PGC_SIGHUP,
>> VACUUM_AUTOVACUUM,
>> +
Hi,
On Fri, Jul 4, 2025 at 9:21 PM Matheus Alcantara
wrote:
>
> The "autovacuum_max_parallel_workers" declared on guc_tables.c mention
> that is capped by "max_worker_process":
> + {
> + {"autovacuum_max_parallel_workers", PGC_SIGHUP,
> VACUUM_AUTOVACUUM,
> +
On Wed Jun 18, 2025 at 5:03 AM -03, Daniil Davydov wrote:
>
> Thanks for the review! Please, see v5 patch :
> 1) GUC variable and field in autovacuum shmem are renamed
> 2) ParallelAutoVacuumReleaseWorkers call moved from parallel.c to
> vacuumparallel.c
> 3) max_parallel_autovacuum_workers is now
Hi,
On Wed, Jun 18, 2025 at 5:37 AM Masahiko Sawada wrote:
>
> On Sun, May 25, 2025 at 10:22 AM Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > Thanks everybody for feedback! I attach a v4 patch to this letter.
> > Main features :
> > 1) 'parallel_autovacuum_workers' reloption - integer valu
On Sun, May 25, 2025 at 10:22 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Fri, May 23, 2025 at 6:12 AM Masahiko Sawada wrote:
> >
> > On Thu, May 22, 2025 at 12:44 AM Daniil Davydov <3daniss...@gmail.com>
> > wrote:
> > >
> > > On Wed, May 21, 2025 at 5:30 AM Masahiko Sawada
Hi,
On Fri, May 23, 2025 at 6:12 AM Masahiko Sawada wrote:
>
> On Thu, May 22, 2025 at 12:44 AM Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > On Wed, May 21, 2025 at 5:30 AM Masahiko Sawada
> > wrote:
> > >
> > > I find that the name "autovacuum_reserved_workers_num" is generic. It
> > >
On Thu, May 22, 2025 at 10:48 AM Sami Imseih wrote:
>
> I started looking at the patch but I have some high level thoughts I would
> like to share before looking further.
>
> > > I find that the name "autovacuum_reserved_workers_num" is generic. It
> > > would be better to have a more specific nam
On Thu, May 22, 2025 at 12:44 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Wed, May 21, 2025 at 5:30 AM Masahiko Sawada wrote:
> >
> > I have some comments on v2-0001 patch
>
> Thank you for reviewing this patch!
>
> > + {
> > + {"autovacuum_reserved_workers_num", PGC_USE
I started looking at the patch but I have some high level thoughts I would
like to share before looking further.
> > I find that the name "autovacuum_reserved_workers_num" is generic. It
> > would be better to have a more specific name for parallel vacuum such
> > as autovacuum_max_parallel_worker
Hi,
On Wed, May 21, 2025 at 5:30 AM Masahiko Sawada wrote:
>
> I have some comments on v2-0001 patch
Thank you for reviewing this patch!
> + {
> + {"autovacuum_reserved_workers_num", PGC_USERSET,
> RESOURCES_WORKER_PROCESSES,
> + gettext_noop("Number of worker processes, reser
On Thu, May 15, 2025 at 10:10 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Fri, May 16, 2025 at 4:06 AM Matheus Alcantara
> wrote:
> > I've reviewed the v1-0001 patch, the build on MacOS using meson+ninja is
> > failing:
> > ❯❯❯ ninja -C build install
> > ninja: Entering director
Hi,
On Fri, May 16, 2025 at 4:06 AM Matheus Alcantara
wrote:
> I've reviewed the v1-0001 patch, the build on MacOS using meson+ninja is
> failing:
> ❯❯❯ ninja -C build install
> ninja: Entering directory `build'
> [1/126] Compiling C object
> src/backend/postgres_lib.a.p/utils_misc_guc_tables.c.o
Hi,
On 09/05/25 15:33, Daniil Davydov wrote:
> Hi,
> As I promised - meet parallel index autovacuum with bgworkers
> (Parallel-index-autovacuum-with-bgworkers.patch). This is pretty
> simple implementation :
> 1) Added new table option `parallel_idx_autovac_enabled` that must be
> set to `true` if
Hi,
As I promised - meet parallel index autovacuum with bgworkers
(Parallel-index-autovacuum-with-bgworkers.patch). This is pretty
simple implementation :
1) Added new table option `parallel_idx_autovac_enabled` that must be
set to `true` if user wants autovacuum to process table in parallel.
2) Ad
> On Mon, May 5, 2025 at 5:21 PM Sami Imseih wrote:
> >
> >
> >> On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com> wrote:
> >> >
> >> > On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada
> >> > wrote:
> >> > >
> >> > > > In current implementation, the leader process sends a signal
On Mon, May 5, 2025 at 5:21 PM Sami Imseih wrote:
>
>
>> On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>> >
>> > On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada
>> > wrote:
>> > >
>> > > > In current implementation, the leader process sends a signal to the
>> > > > a
On Tue, May 6, 2025 at 7:21 AM Sami Imseih wrote:
>
> Perhaps we should only provide a reloption, therefore only tables specified
> by the user via the reloption can be autovacuumed in parallel?
Аfter your comments (earlier in this thread) I decided to do just
that. For now we have reloption, so
On Tue, May 6, 2025 at 6:57 AM Masahiko Sawada wrote:
>
> What I roughly imagined is that we don't need to change the entire
> autovacuum scheduling, but would like autovacuum workers to decides
> whether or not to use parallel vacuum during its vacuum operation
> based on GUC parameters (having a
> On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com>
> wrote:
> >
> > On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada
> wrote:
> > >
> > > > In current implementation, the leader process sends a signal to the
> > > > a/v launcher, and the launcher tries to launch all requested wor
On Sat, May 3, 2025 at 1:10 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada wrote:
> >
> > > In current implementation, the leader process sends a signal to the
> > > a/v launcher, and the launcher tries to launch all requested workers.
> > > But
On Sat, May 3, 2025 at 5:59 AM Sami Imseih wrote:
>
> > I think it would more make
> > sense to maintain the existing autovacuum_max_workers parameter while
> > introducing a new parameter that would either control the maximum
> > number of parallel vacuum workers per autovacuum worker or set a
>
On Sat, May 3, 2025 at 5:28 AM Masahiko Sawada wrote:
>
> > In current implementation, the leader process sends a signal to the
> > a/v launcher, and the launcher tries to launch all requested workers.
> > But the number of workers never exceeds `autovacuum_max_workers`.
> > Thus, we will never ha
On Sat, May 3, 2025 at 3:17 AM Sami Imseih wrote:
>
> I think in most cases, the user will want to determine the priority of
> a table getting parallel vacuum cycles rather than having the autovacuum
> determine the priority. I also see users wanting to stagger
> vacuums of large tables with many
> I think it would more make
> sense to maintain the existing autovacuum_max_workers parameter while
> introducing a new parameter that would either control the maximum
> number of parallel vacuum workers per autovacuum worker or set a
> system-wide cap on the total number of parallel vacuum worker
On Fri, May 2, 2025 at 11:13 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Thu, May 1, 2025 at 8:03 AM Masahiko Sawada wrote:
> >
> > As I understand it, we initially disabled parallel vacuum for
> > autovacuum because their objectives are somewhat contradictory.
> > Parallel vacuum aims
On Fri, May 2, 2025 at 9:58 AM Sami Imseih wrote:
>
> > Once we have parallel heap vacuum, as discussed in thread[1], it would
> > also likely be beneficial to incorporate it into autovacuum during
> > aggressive vacuum or failsafe mode.
>
> IIRC, index cleanup is disabled by failsafe.
Yes. My id
> On Fri, May 2, 2025 at 11:58 PM Sami Imseih wrote:
> >
> > I am generally -1 on the idea of autovacuum performing parallel
> > index vacuum, because I always felt that the parallel option should
> > be employed in a targeted manner for a specific table. if you have a bunch
> > of large tables, s
On Fri, May 2, 2025 at 11:58 PM Sami Imseih wrote:
>
> I am generally -1 on the idea of autovacuum performing parallel
> index vacuum, because I always felt that the parallel option should
> be employed in a targeted manner for a specific table. if you have a bunch
> of large tables, some more imp
On Thu, May 1, 2025 at 8:03 AM Masahiko Sawada wrote:
>
> As I understand it, we initially disabled parallel vacuum for
> autovacuum because their objectives are somewhat contradictory.
> Parallel vacuum aims to accelerate the process by utilizing additional
> resources, while autovacuum is design
Thanks for raising this idea!
I am generally -1 on the idea of autovacuum performing parallel
index vacuum, because I always felt that the parallel option should
be employed in a targeted manner for a specific table. if you have a bunch
of large tables, some more important than others, a/c may end
Hi,
On Wed, Apr 16, 2025 at 4:05 AM Maxim Orlov wrote:
>
> Hi!
>
> The VACUUM command can be executed with the parallel option. As documentation
> states, it will perform index vacuum and index cleanup phases of VACUUM in
> parallel using integer background workers. But such an interesting feat
HI *Maxim Orlov*
Thank you for your working on this ，I like your idea ，but I have a
suggestion ,autovacuum_max_workers is not need change requires restart , I
think those guc are can like
autovacuum_max_workers
+#max_parallel_index_autovac_workers = 0 # this feature disabled by default
+ # (c
Hi!
The VACUUM command can be executed with the parallel option. As
documentation states, it will perform index vacuum and index cleanup phases
of VACUUM in parallel using *integer* background workers. But such an
interesting feature is not used for an autovacuum. After a quick look at
the source
44 matches
Mail list logo
