Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Date
Msg-id CAMkU=1yc78RvRSoST_AMW4gqJ-3D7b9bkn2a1AwutxmFRhyaRg@mail.gmail.com
Whole thread Raw
In response to Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]  (Dilip kumar <dilip.kumar@huawei.com>)
Responses Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]  (Dilip kumar <dilip.kumar@huawei.com>)
List pgsql-hackers
On Monday, June 23, 2014, Dilip kumar <dilip.kumar@huawei.com> wrote:
On 24 June 2014 03:31, Jeff Wrote,

> >  Attached the latest updated patch
> >  1. Rebased the patch to current GIT head.
> >  2. Doc is updated.
> >  3. Supported parallel execution for all db option also.
>
> This patch needs to be rebased after the analyze-in-stages patch,
> c92c3d50d7fbe7391b5fc864b44434.

Thank you for giving your attention to this, I will rebase this..

> Although that patch still needs to some work itself, despite being
> committed, as still loops over the stages for each db, rather than the
> dbs for each stage.

If I understood your comment properly, Here you mean to say that
In vacuum_all_databases instead to running all DB's in parallel, we are running db by db in parallel?

I mean that the other commit, the one conflicting with your patch, is still not finished.  It probably would not have been committed if we realized the problem at the time.  That other patch runs analyze in stages at different settings of default_statistics_target, but it has the loops in the wrong order, so it analyzes one database in all three stages, then moves to the next database.  I think that these two changes are going to interact with each other.  But I can't predict right now what that interaction will look like.   So it is hard for me to evaluate your patch, until the other one is resolved.

Normally I would evaluate your patch in isolation, but since the conflicting patch is already committed (and is in the 9.4 branch) that would probably not be very useful in this case.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Use a signal to trigger a memory context dump?
Next
From: Amit Kapila
Date:
Subject: Re: Wait free LW_SHARED acquisition - v0.2