improving speed of make check-world

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: improving speed of make check-world
Date: 2014-08-15 05:45:16
Message-ID: 53ED9E6C.1080700@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

make check-world creates a temporary installation in every subdirectory
it runs a test in, which is stupid: it's very slow and uses a lot of
disk space. It's enough to do this once per run. That is the essence
of what I have implemented. It cuts the time for make check-world in
half or less, and it saves gigabytes of disk space.

The idea is that we only maintain one temporary installation under the
top-level directory. By looking at the variable MAKELEVEL, we can tell
whether we are the top-level make invocation. If so, make a temp
installation. If not, we know that the upper layers have already done
it and we can just point to the existing temp installation.

I do this by ripping out the temp installation logic from pg_regress and
implementing it directly in the makefiles. This is much simpler and has
additional potential benefits:

The pg_regress temp install mode is actually a combination of two
functionalities: temp install plus temp instance. Until now, you could
only get the two together, but the temp instance functionality is
actually quite useful by itself. It opens up the possibility of
implementing "make check" for external pgxs modules, for example.

Also, you could now run the temp installation step using parallel make,
making it even faster. This was previously disabled because the make
flags would have to pass through pg_regress. It still won't quite work
to run make check-world -j8, say, because we can't actually run the
tests in parallel (yet), but something like make -C src/test/regress
check -j8 should work.

To that end, I have renamed the pg_regress --temp-install option to
--temp-instance. Since --temp-install is only used inside the source
tree, this shouldn't cause any compatibility problems.

MSVC build is not yet adjusted for this. Looking at vcregress.pl, this
should be fairly straightforward.

Attachment Content-Type Size
regress-temp-instance.patch text/x-patch 30.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2014-08-15 06:09:07 Re: strncpy is not a safe version of strcpy
Previous Message Michael Paquier 2014-08-15 05:16:31 Re: pg_shmem_allocations view