Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 16 October 2014 06:05, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Oct 16, 2014 at 8:08 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>
>>
>> I've been trying to review this thread with the thought "what does
>> this give me?". I am keen to encourage contributions and also keen to
>> extend our feature set, but I do not wish to complicate our code base.
>> Dilip's developments do seem to be good quality; what I question is
>> whether we want this feature.
>>
>> This patch seems to allow me to run multiple VACUUMs at once. But I
>> can already do this, with autovacuum.
>>
>> Is there anything this patch can do that cannot be already done with
>> autovacuum?
>
> The difference lies in the fact that vacuumdb (or VACUUM) gives
> the option to user to control the vacuum activity for cases when
> autovacuum doesn't suffice the need, one of the example is to perform
> vacuum via vacuumdb after pg_upgrade or some other maintenance
> activity (as mentioned by Jeff upthread). So I think in all such cases
> having parallel option can give benefit in terms of performance which
> is already shown by Dilip upthread by running some tests (with and
> without patch).

Why do we need 2 ways to do the same thing?

Why not ask autovacuum to do this for you?

Just send a message to autovacuum to request an immediate action. Let
it manage the children and the tasks.

SELECT pg_autovacuum_immediate(nworkers = N, list_of_tables);

Request would allocate an additional N workers and immediately begin
vacuuming the stated tables.

vacuumdb can still issue the request, but the guts of this are done by
the server, not a heavily modified client.

If we are going to heavily modify a client then it needs to be able to
run more than just one thing. Parallel psql would be nice. pg_batch?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services