Re: 9.3 feature proposal: vacuumdb -j # - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: 9.3 feature proposal: vacuumdb -j #
Date
Msg-id 4F161F6B.9020808@dunslane.net
Whole thread Raw
In response to Re: 9.3 feature proposal: vacuumdb -j #  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers

On 01/17/2012 07:09 PM, Jim Nasby wrote:
> On Jan 13, 2012, at 4:15 PM, Christopher Browne wrote:
>> Have two logical tasks:
>> a) A process that manages the list, and
>> b) Child processes doing vacuums.
>>
>> Each time a child completes a table, it asks the parent for another one.
> There is also a middle ground, because having the the scheduling process sounds like a lot more work than what Josh
wasproposing.
 
>
> CREATE TEMP SEQUENCE s;
> SELECT relname, s mod<number of backends>  AS backend_number
>    FROM ( SELECT relname
>             FROM pg_class
>             ORDER BY relpages
> );
>
> Of course, having an actual scheduling process is most likely the most efficient.

We already have a model for this in parallel pg_restore. It would 
probably not be terribly hard to adapt to parallel vacuum.

cheers

andrew



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Group commit, revised
Next
From: Robert Haas
Date:
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?