Re: CI slowdown due to PG_TEST_INITDB_EXTRA_OPTS

On Tue, Aug 11, 2026 at 2:39 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
>
> On Tue, 21 Jul 2026 at 02:56, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > Hi,
> >
> > On 2026-07-20 23:47:16 +0200, Jelte Fennema-Nio wrote:
> > > On Sat, 18 Jul 2026 at 20:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > > It looks like any one job mostly uses the same value of
> > > > PG_TEST_INITDB_EXTRA_OPTS. Could we record what was used to set up
> > > > the template, and allow using it if that matches?
> >
> > That seems like a somewhat complicated mechanism. But mainly I feel like it's
> > a workaround around the config-customization-via-env-var having to go through
> > exactly one file. None of the uses of PG_TEST_INITDB_EXTRA_OPTS in CI actually
> > needs it to be an initdb option, it's just a way to set configuration options
> > for the server via an environment variable.
> >
> > I wonder if the best thing would be to add PG_TEST_SERVER_POSTGRES_OPTS or
> > such, which Cluster.pm and regress.c would add to postgresql.conf.
>
> I don't think it's that complicated. But I'd be fine with
> PG_TEST_SERVER_POSTGRES_OPTS as well. That has the downside that it
> won't work for actual initdb options, but at least CI doesn't use that
> (for now). Some buildfarm members might though.

Hi,

I've scheduled 3 runs on 3 consecutive days (w/o and with v2 patch by Nazir),
[in minutes, from/master -> branch/w patch]
autoconf 23 -> 17, 21 -> 10, 20 -> 16
meson32 16 -> 14, 16 -> 9, 15 -> 13
meson64 29 -> 22, 28 -> 18, 28 -> 22
macOS 28 -> 25, 21 -> 17, 21 -> 20
mingw 22 -> 27?,25 -> 23, 28 -> 26
warnings 32 -> 30, 23 -> 3?, 27 -> 24
winvc1 18 -> 19, 19 -> 26, 16 -> 16
winvc2 17 -> 17, 17 -> 14, 17 -> 16

Take the results with some degree of doubt (I have no idea what is
infrastructure underneath; how overscribed the CPUs were etc.), but those
are consistent, real gains for Linux builds (-33% autoconf, -27% meson32,
23% meson64) during 3 days.

> I was once more wondering why CI is so slow. [..]

Cheer up gents, altough it's like ~ < 25min, I find the full CI of PostgreSQL
still the fastest thing I have ever worked with and it's free. From what
I've worked with, heard or read in terms of complex software/systems it's
leaving the rest of world in the dust in terms of how lightweight/fast it
is ... [one can have it even faster on your hardware if one wants -- using
runners].

-J.