On Tue, Aug 11, 2026 at 2:39 PM Jelte Fennema-Nio <[email protected]> wrote: > > On Tue, 21 Jul 2026 at 02:56, Andres Freund <[email protected]> wrote: > > > > Hi, > > > > On 2026-07-20 23:47:16 +0200, Jelte Fennema-Nio wrote: > > > On Sat, 18 Jul 2026 at 20:48, Tom Lane <[email protected]> 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.
