| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Euler Taveira <euler(at)timbira(dot)com(dot)br> |
| Cc: | Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>, Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
| Date: | 2014-01-16 15:05:12 |
| Message-ID: | 20140116150512.GH4554@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Euler Taveira wrote:
> On 08-11-2013 06:20, Dilip kumar wrote:
> > On 08 November 2013 13:38, Jan Lentfer
> >
> >
> >> For this use case, would it make sense to queue work (tables) in order of their size, starting on the largest one?
> >
> >> For the case where you have tables of varying size this would lead to a reduced overall processing time as it prevents large (read: long processing time) tables to be processed in the last step. While processing large tables at first and filling up "processing slots/jobs" when they get free with smaller tables one after the other would safe overall execution time.
> > Good point, I have made the change and attached the modified patch.
> >
> Don't you submit it for a CF, do you? Is it too late for this CF?
Not too late.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-01-16 15:22:46 | Re: Display oprcode and its volatility in \do+ |
| Previous Message | Andres Freund | 2014-01-16 14:54:32 | Re: Changeset Extraction v7.0 (was logical changeset generation) |