Re: relscan_details.h

On Tue, Sep 17, 2013 at 2:30 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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