Skip site navigation (1) Skip section navigation (2)

Re: 9.3 feature proposal: vacuumdb -j #

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Susanne Ebrecht <susanne(at)2ndquadrant(dot)com>
Subject: Re: 9.3 feature proposal: vacuumdb -j #
Date: 2012-01-17 14:04:47
Message-ID: 201201171504.47925.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tuesday, January 17, 2012 01:33:06 PM Jaime Casanova wrote:
> On Tue, Jan 17, 2012 at 7:23 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On Tuesday, January 17, 2012 01:18:53 PM Susanne Ebrecht wrote:
> >> I would prefer to have an option that the user is able to tell on how
> >> much cores it should be shared. Something like --share-cores=N.
> > 
> > Uhm. -j # does exactly that or am I missing your point?
> 
> not really.
> 
> if you have 12 cores and you say -j 12 you would have 1 process per
> core, with Susanne's suggestion, AFAIUI, you can say -j 12
> --shared-cores=6... so you would only use 6 cores of the 12 and have 2
> processes per core
I don't really get what that should do. If vacuumdb itself is a limit in any 
form in this we did something *very* wrong (in my opinion using processes for 
this is pointless anyway. Using async queries seems to be much easier for this 
special case. Especially for distributing individual commands.).
I don't really see how you could enforce sharing cores on the server side 
(well, there are cpusets, but were sure not introduce usage of that just for 
vacuumdb).

Andres

In response to

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-01-17 14:35:28
Subject: Re: Group commit, revised
Previous:From: Andrew DunstanDate: 2012-01-17 13:55:47
Subject: Re: 9.3 feature proposal: vacuumdb -j #

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group