On Tue, Sep 17, 2013 at 2:30 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >> -1 on header restructuring in the absence of noteworthy compile-time >> benchmark >> improvements. Besides the obvious benchmark of full-build time, one could >> exercise the benefit of fewer header dependencies by modelling the series of >> compile times from running "git pull; make" at each commit for the past >> several months. The latter benchmark is perhaps more favorable. > > I will have a go at measuring things this way.
Personally, I'm not particularly in favor of these kinds of changes. The changes we made last time broke a lot of extensions - including some proprietary EDB ones that I had to go fix. I think a lot of people spent a lot of time fixing broken builds, at EDB and elsewhere, as well as rebasing patches. And the only benefit we have to balance that out is that incremental recompiles are faster, and I'm not really sure how important that actually is. On my system, configure takes 25 seconds and make -j3 takes 65 seconds; so, even a full recompile is pretty darn fast, and an incremental recompile is usually really fast. Now granted this is a relatively new system, but still. I don't want to be too dogmatic in opposing this; I accept that we should, from time to time, refactor things. If we don't, superflouous dependencies will probably proliferate over time. But personally, I'd rather do these changes in bulk every third release or so and keep them to a minimum in between times, so that we're not forcing people to constantly decorate their extensions with new #if directives. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers