Re: [HACKERS] Need a builtin way to run all tests faster manner - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Need a builtin way to run all tests faster manner
Date
Msg-id 20170307005330.5tgjfyqjm3iczoch@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Need a builtin way to run all tests faster manner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Need a builtin way to run all tests faster manner  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: [HACKERS] Need a builtin way to run all tests faster manner  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 2017-03-06 19:45:27 -0500, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Andres Freund (andres@anarazel.de) wrote:
> >> I'm not quite sure what the best way to attack this is, but I think we
> >> need to do something.
>
> > I tend to agree with this, though I haven't got any great answers,
> > unfortunately.
>
> I don't want to reduce test coverage either.  I think the most painless
> way to improve matters would just be to work harder on running tests in
> parallel.  I think most devs these days do most of their work on 4- or
> 8-core machines, yet almost everything except the core regression tests
> is depressingly serial.  I think we could likely get a 2x or better
> reduction in total runtime without too much work just by attacking that.

A lot more probably, based on my preliminary tests / my local test
script.

I'm just not quite sure what the best way is to make it easier to run
tests in parallel within the tree.

The best I can come up so far is a toplevel target that creates the temp
install, starts a cluster and then runs the 'installcheck-or-check'
target on all the subdirectories via recursion. Individual makefiles can
either use the pre-existing cluster (most of of contrib for example), or
use the temporary install and run their pre-existing check target using
that (the tap tests, test_decoding, ...).

Requires editing a bunch of Makefiles to take advantage.  But I don't
really see anything that doesn't require that.

- Andres



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Patch to implement pg_current_logfile() function
Next
From: David Rowley
Date:
Subject: [HACKERS] Small fix to postgresql.conf.sample's comment on max_parallel_workers