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