From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
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 13:07:07 -0800
Message-ID: <20180124210707.k3sju7bv4xxeoyik@alap3.anarazel.de> (raw)
In-Reply-To: <19265.1516827496@sss.pgh.pa.us>
References: <20180124182018.jx2h4wp6twqo7xix@alap3.anarazel.de>
<20180124201826.g6vhuewpnycpt3ta@alvherre.pgsql>
<20180124204359.ognamsfdqbrfbazd@alap3.anarazel.de>
<19265.1516827496@sss.pgh.pa.us>
Hi,
On 2018-01-24 15:58:16 -0500, Tom Lane wrote:
> Yeah. We already have topo sort code in pg_dump, maybe we could push that
> into someplace like src/common or src/fe_utils? Although pg_dump hasn't
> got any need for edge weights, so maybe sharing code isn't worth it.
I suspect it may be more work to share than worth it, but either way, it
shouldn't be too hard. Hm, isn't dbObjectTypePriority kinda an edge
weight? Seems like we properly could implement it as that.
> We could flush the existing schedule files and use a simple format like
> testname: list of earlier tests it depends on
> (I guess there would be more properties than just the dependencies,
> but still not hard to parse.)
Yea, I think there'd need to be a few more. There's some tests that use
multiple connections, and I suspect it'll be useful to have "implicit"
ordering dependencies for a few test, like a "barrier". Otherwise
e.g. the tablespace test will be annoying to order.
> > If we keep the timings from an earlier
> > run somwhere, we can use the timing of runs as edge weights, making the
> > schedule better.
>
> I think we could just use constant values hand-coded in the schedule file.
> It might occasionally be worth updating them, but realistically it's not
> going to matter that they be very accurate. Probably weights like 1, 2,
> and 3 would be plenty ;-)
The reason I like the idea of using prior tests as scheduling input is
that the slowness actually depends a lot on the type of machine its run
on, and more importantly on things like valgrind, CCA, fsync=on/off,
jit=on/off (far most expensive tests is e.g. the recursion test in
errors.sql :)).
Greetings,
Andres Freund
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: andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, thomas.munro@enterprisedb.com, pgsql-hackers@postgresql.org
Subject: Re: pgsql: Add parallel-aware hash joins.
In-Reply-To: <20180124210707.k3sju7bv4xxeoyik@alap3.anarazel.de>
* 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