Excerpts from Tom Lane's message of vie jun 15 21:06:21 -0400 2012:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > This patch splits htup.h in two pieces -- the first one (tupbasics.h;
> > not wedded to the name) does not include many other headers and is just
> > enough to have other parts of the code create tuples and pass them
> > around, to be used by most other headers. The other one (which keeps
> > the name htup.h) contains internal tuple stuff (struct declarations
> > etc).
>
> > Before patch, htup.h is directly or indirectly included by 364 .c files
> > in src/backend; after patch, that's reduced to 299 files (that's 65
> > files less to compile if you modify the header).
>
> That's kind of a disappointing result --- if we're going to split htup.h
> into public and private parts, I would have hoped for a much smaller
> inclusion footprint for the private part. Maybe you could adjust the
> boundary between public and private parts a bit more? If we can't cut
> the footprint I'm inclined to think this isn't worth the code churn.
Yeah, I have another version of the patch (attached) that includes
HeapTupleData in the public part; this means catcache.h does not need
htup.h, which was the main propagation vector in the original patch.
With that, 162 .c files include htup.h -- about 130 of them do so
directly, and the rest do so through either relscan.h or tuptoaster.h.
Is this enough? I think the next step would require moving
HeapTupleHeaderData to the public header as well; I haven't checked to
see how much better it gets. It would require copying some of the
other includes in htup.h into the public header, though, so there is a
tradeoff.
(Another idea: maybe we could split in three parts rather than two).
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support