Re: Parallel make problem with git master
От | Robert Haas |
---|---|
Тема | Re: Parallel make problem with git master |
Дата | |
Msg-id | AANLkTinfby2e-LuX=oPskw8xuXkq6u6-5ebyYj3O5Nne@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel make problem with git master (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
On Tue, Mar 8, 2011 at 9:07 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > The bit I looked at, at the time, was src/backend/mb/conversion_procs, > because that was where the biggest hit on parallelization was taken (a > single lib at a time -- the real time CPU usage chart clearly showed the > problem. Not sure if that's still a problem). I think it is, based on having noticed it spend what seemed like a disproportionate amount of time on that stuff when building, but I haven't actually tried to measure it. >> I'm not sure whether it makes sense to go that far or not. But I >> think it'd make sense to at least try this for the backend. It does >> seem pretty silly to have a Makefile in every single directory. > > We already do that for the backend. Not exactly a single Makefile, but > the dependencies are all declared in indirectly in src/backend/Makefile > with the common.mk tricks. I'm not sure that's really the same thing. It'd be interesting to redo it with just one Makefile and see whether it's faster. > Where it doesn't work is in the other subdirs, c.f. the current problem > with interfaces/libpq and interfaces/ecpg. It would be a lot more > difficult to fix there, I think, but maybe I'm wrong. Yeah, that's a problem. I wondered if supplying -p to mkdir would ameliorate the problem to some degree... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: