From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Add parallel-aware hash joins.
Date: Wed, 24 Jan 2018 15:36:35 -0500
Message-ID: <18096.1516826195@sss.pgh.pa.us> (raw)
In-Reply-To: <20180124201826.g6vhuewpnycpt3ta@alvherre.pgsql>
References: <20180124201826.g6vhuewpnycpt3ta@alvherre.pgsql>
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Andres Freund wrote:
>> Besides larger groups, starting the next test(s) earlier, another way to
>> gain pretty large improvements would be a test schedule feature that
>> allowed to stat dependencies between tests. So instead of manually
>> grouping the schedule, have 'numerology' state that it depends on int2,
>> int4, int8, float4, float8, which means it can actually be started
>> earlier than it currently can in many cases.
> Yeah, I proposed this a decade ago but never had the wits to write the
> code.
There'd be a lot of followup work to sanitize the tests better. For
instance, if two tests transiently create tables named "foo", it doesn't
matter as long as they're not in the same group. It would matter with
this.
There are things we could do to mitigate that --- one attractive idea
is to have each test create its own schema for transient objects.
The limiting factor is that we don't want the test scripts to change
so much that back-patching tests becomes impossible. (Or at least,
I'd not like that.)
I'm concerned that we'd end up with a higher number of irreproducible
test failures with no good way to investigate them.
> It would be very useful for running tests standalone, too -- much as I
> dislike 'make installcheck' taking half a minute, I dislike much more
> having to take 5 minutes each time to figure out that create_table
> depends on box, polygon, create_function, yadda yadda.
Yeah, if we could say "run just this test and its needed precursors",
that'd be a huge win in a lot of situations.
Definitely seems like an idea worth pursuing.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, andres@anarazel.de, robertmhaas@gmail.com, thomas.munro@enterprisedb.com, pgsql-hackers@postgresql.org
Subject: Re: pgsql: Add parallel-aware hash joins.
In-Reply-To: <18096.1516826195@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox