Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Date: 2020-09-22 07:20:38
Message-ID: CAApHDvqoRtZ1bcLyuY64ePr3RiKg9Re-r3VTtfVs9Tp25ukwRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 21 Sep 2020 at 19:15, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> On 2020-09-21 05:48, Amit Kapila wrote:
> > What according to you should be the behavior here and how will it be
> > better than current?
>
> I think if I write VACUUM (PARALLEL 5), it should use up to 5 workers
> (up to the number of indexes), even if max_parallel_maintenance_workers
> is 2.

It would be good if we were consistent with these parallel options.
Right now max_parallel_workers_per_gather will restrict the
parallel_workers reloption. I'd say this
max_parallel_workers_per_gather is similar to
max_parallel_maintenance_workers here and the PARALLEL vacuum option
is like the parallel_workers reloption.

If we want VACUUM's parallel option to work the same way as that then
max_parallel_maintenance_workers should restrict whatever is mentioned
in VACUUM PARALLEL.

Or perhaps this is slightly different as the user is explicitly asking
for this in the command, but you could likely say the same about ALTER
TABLE <table> SET (parallel_workers = N); too.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-09-22 07:38:06 Re: Use appendStringInfoString and appendPQExpBufferStr where possible
Previous Message David Rowley 2020-09-22 07:08:12 Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path