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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-01-17 14:35:28 | Re: Group commit, revised |
Previous Message | Andrew Dunstan | 2012-01-17 13:55:47 | Re: 9.3 feature proposal: vacuumdb -j # |