Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Re: 7.3 docs
Date: Mon, 6 Mar 2006 10:57:08 +0100
Message-ID: <6BCB9D8A16AC4241919521715F4D8BCEA350C8@algol.sollentuna.se>
Thread-Topic: [pgsql-www] 7.3 docs
Thread-Index: AcY/wA9hM7MT/d7+Q9y5MfSzKMMHNwBO4izw
From: "Magnus Hagander" <mha@sollentuna.net>
To: "Marc G. Fournier" <scrappy@postgresql.org>,
	"Joshua D. Drake" <jd@commandprompt.com>
Cc: "Robert Treat" <xzilla@users.sourceforge.net>, <pgsql-www@postgresql.org>

> >> I thought that was pre-8.1. :-)
> >>=20
> >> But yeah, it's a point. I'll look towards other more=20
> efficient ways=20
> >> to decreas the docs build process :-)
> >>=20
> > I don't think we need to keep the 7.3 interactive docs...=20
> The static=20
> > docs are probably still good to have around.
>=20
> I'm about 50-50 split on this one ... but, if we are still=20
> actively supporting a version of PostgreSQL, we are=20
> acknowledging that ppl *are* still using it, and, therefore,=20
> ppl could still be annotating the interactie docs ...
>=20
> But ... the docs themselves are pretty static, so *why* are=20
> they being regenerated on a regular basis in the first place?=20
>  Couldn't you just regenerate those files that have comments=20
> attached to them, instead of all of them each time?  It would=20
> make the mirrors faster too, since they wouldn't have to pull=20
> down new copies of the complete docs each time, but only=20
> those pages that have actually had changes made to them ...

Yeah, that would be the "more efficient ways". It's the main problem
with how the site is built now - there's basically a mirror script that
runs across the whole site as a web-browser and pulls it all down. It
takes about an hour ion the new vm with docs incldued (on the old one,
that would be 20+ hours). When nothing has changed it the docs and very
little in the main site (the normal way) it takes 5-10 minutes less.

The good news is that with the new VM we now appear completeyl CPU-bound
with the php mirror script instead of I/O bound as we were with unionfs.

Oh, and we don't actually *update* the other files. It takes almost as
long to verify that they haven't changed, since we then pull down the
page through http and compare it to the file. We only write it when it
has changed. And yes, that optimisation helped a lot for the mirror
syncup time.

//Magnus