agora inbox for [email protected]  

help / color / mirror / Atom feed

[PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
486+ messages / 2 participants
[nested] [flat]

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

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

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

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


--lyfxwjjve3vodszg--





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

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

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

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread

* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners
@ 2026-06-03 17:41  Andres Freund <[email protected]>
  0 siblings, 0 replies; 486+ messages in thread

From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw)

Without windows-vs is about 10min slower than the others tasks (windows-vs is
currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating
experience. It seems worth "sacrificing" one of the 20 available concurrent
jobs to avoid that. This reduces the time down to about 18m.

ci-os-only: windows
---
 .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml
index 93b17af46df..83ee93ce5d6 100644
--- a/.github/workflows/pg-ci.yml
+++ b/.github/workflows/pg-ci.yml
@@ -723,8 +723,13 @@ jobs:
 
 
   # Job: Windows - Visual Studio
+  #
+  # If we were to execute tests in this job serially, this would be the
+  # slowest job by a good margin. To avoid that, use a matrix in combination
+  # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests
+  # across two runners.
   windows-vs:
-    name: Windows - Visual Studio
+    name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}}
     needs: [setup, sanity-check]
     if: |
       !cancelled() &&
@@ -732,6 +737,17 @@ jobs:
       needs.sanity-check.result != 'failure'
     runs-on: windows-2022
     timeout-minutes: 60
+
+    # As described at the top of the task, split the tests across two runners
+    # for performance. The gains from additional concurrency diminish
+    # relatively quickly, due to each instance having to install dependencies
+    # and build postgres.
+    strategy:
+      fail-fast: false
+      matrix:
+        num_slices: [2]
+        slice: [1, 2]
+
     env:
       # Avoid port conflicts between concurrent tap tests
       PG_TEST_USE_UNIX_SOCKETS: 1
@@ -885,6 +901,11 @@ jobs:
 
       - name: Test world
         env:
+          # As described at the top of the task, split the tests across two
+          # runners for performance.  It's not the prettiest to implement this
+          # by prepending to MTEST_TARGET, but a more complicated solution
+          # doesn't seem worth it.
+          MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}}
           ADDITIONAL_SETUP: |
             call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64
         run: *meson_test_world_cmd
-- 
2.54.0.380.gc69baaf57b


--lyfxwjjve3vodszg--





^ permalink  raw  reply  [nested|flat] 486+ messages in thread