[PATCH v33 3/5] Move conversion of a "historic" to MVCC snapshot to a separate function.

agora inbox for [email protected]  
help / color / mirror / Atom feed

[PATCH v33 3/5] Move conversion of a "historic" to MVCC snapshot to a separate function.
484+ messages / 2 participants
[nested] [flat]

* [PATCH v33 3/5] Move conversion of a "historic" to MVCC snapshot to a separate function.
@ 2026-01-27 10:48 Antonin Houska <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Antonin Houska @ 2026-01-27 10:48 UTC (permalink / raw)

The conversion is now handled by SnapBuildMVCCFromHistoric(). REPACK
CONCURRENTLY will also need it.
---
 src/backend/replication/logical/snapbuild.c | 59 +++++++++++++++++----
 src/backend/utils/time/snapmgr.c            |  3 +-
 src/include/replication/snapbuild.h         |  1 +
 src/include/utils/snapmgr.h                 |  1 +
 4 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 7f79621b57e..a738ad8a864 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -440,10 +440,7 @@ Snapshot
 SnapBuildInitialSnapshot(SnapBuild *builder)
 {
 	Snapshot	snap;
-	TransactionId xid;
 	TransactionId safeXid;
-	TransactionId *newxip;
-	int			newxcnt = 0;
 
 	Assert(XactIsoLevel == XACT_REPEATABLE_READ);
 	Assert(builder->building_full_snapshot);
@@ -485,7 +482,35 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 
 	MyProc->xmin = snap->xmin;
 
-	/* allocate in transaction context */
+	/* Convert the historic snapshot to MVCC snapshot. */
+	return SnapBuildMVCCFromHistoric(snap, true);
+}
+
+/*
+ * Turn a historic MVCC snapshot into an ordinary MVCC snapshot.
+ *
+ * Unlike a regular (non-historic) MVCC snapshot, the 'xip' array of this
+ * snapshot contains not only running main transactions, but also their
+ * subtransactions. On the other hand, 'subxip' will usually be empty. This
+ * difference does not affect the result of XidInMVCCSnapshot() because it
+ * searches both in 'xip' and 'subxip'.
+ *
+ * Pass true for 'in_place' if you don't care about modifying the source
+ * snapshot. If you need a new instance, and one that was allocated as a
+ * single chunk of memory, pass false.
+ */
+Snapshot
+SnapBuildMVCCFromHistoric(Snapshot snapshot, bool in_place)
+{
+	TransactionId xid;
+	TransactionId *oldxip = snapshot->xip;
+	uint32		oldxcnt = snapshot->xcnt;
+	TransactionId *newxip;
+	int			newxcnt = 0;
+	Snapshot	result;
+
+	Assert(snapshot->snapshot_type == SNAPSHOT_HISTORIC_MVCC);
+
 	newxip = palloc_array(TransactionId, GetMaxSnapshotXidCount());
 
 	/*
@@ -494,7 +519,7 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 	 * classical snapshot by marking all non-committed transactions as
 	 * in-progress. This can be expensive.
 	 */
-	for (xid = snap->xmin; NormalTransactionIdPrecedes(xid, snap->xmax);)
+	for (xid = snapshot->xmin; NormalTransactionIdPrecedes(xid, snapshot->xmax);)
 	{
 		void	   *test;
 
@@ -502,7 +527,7 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 		 * Check whether transaction committed using the decoding snapshot
 		 * meaning of ->xip.
 		 */
-		test = bsearch(&xid, snap->xip, snap->xcnt,
+		test = bsearch(&xid, snapshot->xip, snapshot->xcnt,
 					   sizeof(TransactionId), xidComparator);
 
 		if (test == NULL)
@@ -519,11 +544,25 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 	}
 
 	/* adjust remaining snapshot fields as needed */
-	snap->snapshot_type = SNAPSHOT_MVCC;
-	snap->xcnt = newxcnt;
-	snap->xip = newxip;
+	snapshot->xcnt = newxcnt;
+	snapshot->xip = newxip;
 
-	return snap;
+	if (in_place)
+		result = snapshot;
+	else
+	{
+		result = CopySnapshot(snapshot);
+
+		/* Restore the original values so the source is intact. */
+		snapshot->xip = oldxip;
+		snapshot->xcnt = oldxcnt;
+
+		/* newxip has been copied */
+		pfree(newxip);
+	}
+	result->snapshot_type = SNAPSHOT_MVCC;
+
+	return result;
 }
 
 /*
diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c
index 2e6197f5f35..3af1b366adf 100644
--- a/src/backend/utils/time/snapmgr.c
+++ b/src/backend/utils/time/snapmgr.c
@@ -213,7 +213,6 @@ typedef struct ExportedSnapshot
 static List *exportedSnapshots = NIL;
 
 /* Prototypes for local functions */
-static Snapshot CopySnapshot(Snapshot snapshot);
 static void UnregisterSnapshotNoOwner(Snapshot snapshot);
 static void FreeSnapshot(Snapshot snapshot);
 static void SnapshotResetXmin(void);
@@ -604,7 +603,7 @@ SetTransactionSnapshot(Snapshot sourcesnap, VirtualTransactionId *sourcevxid,
  * The copy is palloc'd in TopTransactionContext and has initial refcounts set
  * to 0.  The returned snapshot has the copied flag set.
  */
-static Snapshot
+Snapshot
 CopySnapshot(Snapshot snapshot)
 {
 	Snapshot	newsnap;
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index ccded021433..34383dea776 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -73,6 +73,7 @@ extern void FreeSnapshotBuilder(SnapBuild *builder);
 extern void SnapBuildSnapDecRefcount(Snapshot snap);
 
 extern Snapshot SnapBuildInitialSnapshot(SnapBuild *builder);
+extern Snapshot SnapBuildMVCCFromHistoric(Snapshot snapshot, bool in_place);
 extern const char *SnapBuildExportSnapshot(SnapBuild *builder);
 extern void SnapBuildClearExportedSnapshot(void);
 extern void SnapBuildResetExportedSnapshotState(void);
diff --git a/src/include/utils/snapmgr.h b/src/include/utils/snapmgr.h
index b8c01a291a1..de824945f0b 100644
--- a/src/include/utils/snapmgr.h
+++ b/src/include/utils/snapmgr.h
@@ -63,6 +63,7 @@ extern Snapshot GetTransactionSnapshot(void);
 extern Snapshot GetLatestSnapshot(void);
 extern void SnapshotSetCommandId(CommandId curcid);
 
+extern Snapshot CopySnapshot(Snapshot snapshot);
 extern Snapshot GetCatalogSnapshot(Oid relid);
 extern Snapshot GetNonHistoricCatalogSnapshot(Oid relid);
 extern void InvalidateCatalogSnapshot(void);
-- 
2.47.3


--r7amdyq3rmktb267
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
	filename="v33-0004-Add-CONCURRENTLY-option-to-REPACK-command.patch"



^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41 Andres Freund <[email protected]>
  0 siblings, 0 replies; 484+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 484+ messages in thread

end of thread, other threads:[~2026-06-03 17:41 UTC | newest]

Thread overview: 484+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-27 10:48 [PATCH v33 3/5] Move conversion of a "historic" to MVCC snapshot to a separate function. Antonin Houska <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>
2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox