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

Tom Lane wrote:
> Dilip kumar <dilip.kumar@huawei.com> writes:
> > On 15 July 2014 19:01, Magnus Hagander Wrote,
> >> I am late to this game, but the first thing to my mind was - do we
> >> really need the whole forking/threading thing on the client at all?
> 
> > Thanks for the review, I understand you point, but I think if we have do this directly by independent connection, 
> > It's difficult to equally divide the jobs b/w multiple independent connections.
> 
> That argument seems like complete nonsense.  You're confusing work
> allocation strategy with the implementation technology for the multiple
> working threads.  I see no reason why a good allocation strategy couldn't
> work with either approach; indeed, I think it would likely be easier to
> do some things *without* client-side physical parallelism, because that
> makes it much simpler to handle feedback between the results of different
> operational threads.

So you would have one initial connection, which generates a task list;
then open N libpq connections.  Launch one vacuum on each, and then
sleep on select() on the three sockets.  Whenever one returns
read-ready, the vacuuming is done and we send another item from the task
list.  Repeat until tasklist is empty.  No need to fork anything.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services