Tom Lane wrote: > Dilip kumar <dilip.ku...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
