Re: relscan_details.h

On Tue, Sep 17, 2013 at 05:54:04PM -0300, Alvaro Herrera wrote:
> Robert Haas escribi?:
>
> > 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.
>
> Fortunately the machines I work on now are also reasonably fast. There
> was a time when my desktop was so slow that it paid off to tweak certain
> file timestamps to avoid spurious recompiles. Now I don't have to
> worry. But it still annoys me that I have enough time to context-switch
> to, say, the email client or web browser, from where I don't switch back
> so quickly; which means I waste five or ten minutes for a task that
> should have taken 20 seconds.

Right. If we can speed up a representative sample of incremental recompiles
by 20%, then I'm on board. At 3%, probably not. (Alas, even 20% doesn't move
it out of the causes-context-switch category. For that, I think you need
fundamentally smarter tools.)

> Now, htup_details.h was a bit different than the case at hand because
> there's evidently lots of code that want to deal with the guts of
> tuples, but for scans you mainly want to start one, iterate and finish,
> but don't care much about the innards. So the cleanup work required is
> going to be orders of magnitude smaller.

There will also be the folks who must add heapam.h and/or genam.h includes
despite formerly getting it/them through execnodes.h. That's not ugly like
"#if PG_VERSION_NUM ...", but it's still work for authors.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com