On Thu, Oct 15, 2020 at 9:02 AM Amit Kapila wrote:
>
> On Mon, Oct 5, 2020 at 8:11 AM Amit Kapila wrote:
> >
> > On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada
> > wrote:
> > >
> > > To make the behavior of parallel vacuum more consistent with other
> > > parallel maintenance commands (i.g., onl
On Mon, Oct 5, 2020 at 8:11 AM Amit Kapila wrote:
>
> On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada
> wrote:
> >
> > To make the behavior of parallel vacuum more consistent with other
> > parallel maintenance commands (i.g., only parallel INDEX CREATE for
> > now), as a second idea, can we make
On Mon, 5 Oct 2020 at 11:21, Robert Haas wrote:
>
> On Sat, Oct 3, 2020 at 9:25 AM Masahiko Sawada
> wrote:
> > To make the behavior of parallel vacuum more consistent with other
> > parallel maintenance commands (i.g., only parallel INDEX CREATE for
> > now), as a second idea, can we make use of
At Sat, 3 Oct 2020 22:25:14 +0900, Masahiko Sawada
wrote in
> On Sat, 3 Oct 2020 at 20:03, Amit Kapila wrote:
> >
> > On Wed, Sep 30, 2020 at 9:23 PM Robert Haas wrote:
> > >
> > > On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> > > > It would be good if we were consistent with these pa
On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada
wrote:
>
> On Sat, 3 Oct 2020 at 20:03, Amit Kapila wrote:
> >
> > On Wed, Sep 30, 2020 at 9:23 PM Robert Haas wrote:
> > >
> > > On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> > > > It would be good if we were consistent with these parallel
On Sat, Oct 3, 2020 at 9:25 AM Masahiko Sawada
wrote:
> To make the behavior of parallel vacuum more consistent with other
> parallel maintenance commands (i.g., only parallel INDEX CREATE for
> now), as a second idea, can we make use of parallel_workers reloption
> in parallel vacuum case as well
On Sat, Oct 3, 2020 at 7:03 AM Amit Kapila wrote:
> But the same is true for the 'Create Index' operation as well where we
> follow the same thing. We will use the number of workers as specified
> in reloption (parallel_workers) which is then limited by
> max_parallel_maintenance_workers.
Well, t
On Sat, 3 Oct 2020 at 20:03, Amit Kapila wrote:
>
> On Wed, Sep 30, 2020 at 9:23 PM Robert Haas wrote:
> >
> > On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> > > It would be good if we were consistent with these parallel options.
> > > Right now max_parallel_workers_per_gather will restri
On Wed, Sep 30, 2020 at 9:23 PM Robert Haas wrote:
>
> On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> > 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_
On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> 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_mainten
On Tue, Sep 29, 2020 at 3:13 PM Peter Eisentraut
wrote:
>
> On 2020-09-26 07:32, Amit Kapila wrote:
> > This is exactly my feeling too. But how about changing documentation a
> > bit as proposed above [1] to make it precise.
> >
> > [1] -
> > https://www.postgresql.org/message-id/CAA4eK1LQWXS_4Rw
On 2020-09-26 07:32, Amit Kapila wrote:
This is exactly my feeling too. But how about changing documentation a
bit as proposed above [1] to make it precise.
[1] -
https://www.postgresql.org/message-id/CAA4eK1LQWXS_4RwLo%2BWT7jusGnBkUvXO73xQOCsydWLYBpLBEg%40mail.gmail.com
Yes, making the docum
On Tue, Sep 22, 2020 at 12:50 PM David Rowley wrote:
>
> On Mon, 21 Sep 2020 at 19:15, Peter Eisentraut
> 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
On Mon, 21 Sep 2020 at 19:15, Peter Eisentraut
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 index
On Mon, Sep 21, 2020 at 12:45 PM Peter Eisentraut
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 in
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.
--
Peter Eise
On Sun, Sep 20, 2020 at 7:15 PM Peter Eisentraut
wrote:
>
> On 2020-09-19 13:24, Amit Kapila wrote:
> >> I think the implemented behavior is wrong.
> >
> > It is the same as what we do for other parallel operations, for
> > example, we limit the number of parallel workers for parallel create
> > i
On 2020-09-19 13:24, Amit Kapila wrote:
I think the implemented behavior is wrong.
It is the same as what we do for other parallel operations, for
example, we limit the number of parallel workers for parallel create
index by 'max_parallel_maintenance_workers' and parallel scan
operations are li
On Sat, Sep 19, 2020 at 4:28 PM Peter Eisentraut
wrote:
>
> On 2020-09-19 11:37, Amit Kapila wrote:
> > I think we can change the documentation for parallel option to explain
> > it better. How about: "Perform index vacuum and index cleanup phases
> > of VACUUM in parallel using integer background
On 2020-09-19 11:37, Amit Kapila wrote:
I think we can change the documentation for parallel option to explain
it better. How about: "Perform index vacuum and index cleanup phases
of VACUUM in parallel using integer background workers (for the
details of each vacuum phase, please refer to Table 2
On Sat, Sep 19, 2020 at 1:58 PM Peter Eisentraut
wrote:
>
> If I read the code correctly, the VACUUM PARALLEL option is capped by
> the active max_parallel_maintenance_workers setting. So if I write
> VACUUM (PARALLEL 5), it will still only do 2 by default. Is that
> correct?
Yeah, but there is
21 matches
Mail list logo
