Just how far can the FOR UPDATE SKIP LOCKED Postgres queue go?

A garbage collected benchmark of a FOR UPDATE SKIP LOCKED job queue on Postgres 18, capped at 1 CPU, found throughput peaking near 375 jobs/s at 64 workers, before the 100 connection slots filled. CPU hit 86% while memory stayed well under the cap. At 128 workers throughput fell to about 200 jobs/s and 29 workers failed to connect. A shared pool of 20 connections reached 652 jobs/s, though the client process may have been a limit. It is a single run with simulated 100ms jobs.