Re: relscan_details.h - Mailing list pgsql-hackers

From Noah Misch
Subject Re: relscan_details.h
Date
Msg-id 20130918222610.GB342709@tornado.leadboat.com
Whole thread Raw
In response to Re: relscan_details.h  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Dead code or buggy code?
Next
From: "MauMau"
Date:
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.