Re: New regression test time

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robins Tharakan <tharakan(at)gmail(dot)com>
Subject: Re: New regression test time
Date: 2013-06-29 19:57:42
Message-ID: 51CF3C36.401@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> I see two problems with this report:
> 1. it creates a new installation for each run,

Yes, I'm running "make check"

> 2. it only uses the serial schedule.

Um, no:

parallel group (19 tests): limit prepare copy2 plancache xml returning
conversion rowtypes largeobject temp truncate polymorphism with
without_oid sequence domain rangefuncs alter_table plpgsql

Out of curiosity, I tried a serial run (MAX_CONNECTIONS=1), which took
about 39s (with patches).

> I care more about the parallel schedule than the serial one, because
> since it obviously runs in less time, then I can run it often and not
> worry about how long it takes. On the other hand, the cost of the extra
> initdb obviously means that the percentage is a bit lower than if you
> were to compare test run time without considering the initdb step.

Possibly, but I know I run "make check" not "make installcheck" when I'm
testing new code. And the buildfarm, afaik, runs "make check". And,
for that matter, who the heck cares?

The important thing is that "make check" still runs in < 30 seconds on a
standard laptop (an ultraportable, even), so it's not holding up a
change-test-change-test cycle. If you were looking to prove something
else, then go for it.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-06-29 20:00:34 Re: Bugfix and new feature for PGXS
Previous Message Jeff Janes 2013-06-29 19:46:14 Re: Spin Lock sleep resolution