| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de>, "Euler Taveira" <euler(at)timbira(dot)com(dot)br> |
| Subject: | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
| Date: | 2014-07-16 04:28:34 |
| Message-ID: | 11450.1405484914@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dilip kumar <dilip(dot)kumar(at)huawei(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2014-07-16 04:34:20 | Re: Bug in spg_range_quad_inner_consistent for adjacent operator (was Re: Add a filed to PageHeaderData) |
| Previous Message | Noah Misch | 2014-07-16 04:25:55 | Re: Deadlocks in HS (on 9.0 :( ) |