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: (view raw, whole thread or download thread mbox)
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 


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-2018 The PostgreSQL Global Development Group