CI: run slow classes that have not failed in five weeks off the PR path: 101 Darling classes (35% of shard time) and 35 Lite classes #5946

Claude posting for Erik Darling.

The Darling PostgreSQL shards decide how long a PR run takes, and about a third of their time goes to slow test classes that have not failed in five weeks. This issue proposes to run those classes in the nightly and on dev pushes, and on a PR only when the change reaches them. That is the mechanism #5510 already uses for 27 classes. The candidates are 101 Darling classes (35% of the Darling shard time) and 35 Lite classes (27% of the Lite test time).

Source: GitHub Actions data for build.yml from 2026-10-09 to 2026-10-16, CI failure logs from 2026-09-07 to 2026-10-07 and from 2026-10-09 to 2026-10-16, .github/scripts/darling-shard-weights.json at dev 67835f03d, and one full Lite run on Windows from 2026-10-07.

The long pole (measured)

• A Darling PostgreSQL shard takes a median of 11.3 minutes: 1.6 minutes of setup and 9.3 of tests. There are 6 shards per run.
• A Darling shard is the last test job to finish in 270 of 405 PR runs that ran tests.
• PR runs take a median of 22.6 minutes of wall time.

The rule for a candidate

A class is a candidate when all of these are true:

• It takes 5 seconds or more: weighted seconds from darling-shard-weights.json for Darling, and seconds in one full Windows run for Lite.
• It failed no CI job in either failure window above. October 8 is not covered.
• It does not carry [Trait("Cost", "Slow")] already.
• It is not a Guard class.

Expected effect (inferred, not measured)

The Darling weights model each class's share of a shard's wall time. So taking 35% of them out of PR runs would cut the Darling shards' test time by about a third. That is about 19 of the 55 runner-minutes of Darling test time per PR run, and about 3 minutes of wall time. The Lite saving is smaller, about 4 runner-minutes. Measure both after the change.

Proposal

1. Add [Trait("Cost", "Slow")] to the candidates below, so the existing Pull requests skip 27 slow, never-failed test classes unless the change reaches them (#5459) #5510 rule skips them on a PR unless the change reaches them.
2. Re-run the rule every month, from the latest weights and failure history. Take the trait off any class that failed in the window.
3. The nightly and dev pushes keep running everything.

Risk

• A regression in one of these classes fails on the dev push after the merge, not in the PR. Dev pushes run everything today, so that is one merge later.
• Somebody must read nightly and dev push failures every day.
• "Has not failed" is not "has no value". These classes stay. They only move off the PR path.