Re: Parallel make problem with git master
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter_e@gmx.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-03-08T14:33:36Z
Lists: 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