On Tue, Feb 10, 2026, at 4:45 AM, Álvaro Herrera wrote: > On 2025-Jul-14, Tom Lane wrote: > > > "Scott Mead" <[email protected]> writes: > > > I'd like to re-open the discussion for this commitfest item. I > > > still have not been able to find a value for parallel_setup_cost > > > that makes good decisions about parallelism on a user's behalf. I > > > believe that setting the SIGHUP-able max_parallel_workers_per_gather > > > to 0 by default is still the best way to prevent runaway parallel > > > execution behavior. > > > > I still think that proposal has no chance of getting off the ground. > > > > I do agree that the current default cost settings for parallel query > > are over-optimistic and allow us to choose PQ when we shouldn't. > > This appears to have been the decision we took on this: we won't change > the default; users affected by this can already turn > max_parallel_workers_per_gather to 0; most users benefit from it being > nonzero. > > What we could probably do, is improve the observability around parallel > worker costs, so that people *know* that they need to do change the value. > What do users need to pay attention to? Are there metrics we should > expose? > > At this point I think we should mark this commitfest entry as rejected. > https://commitfest.postgresql.org/patch/5751/
That's fair enough, interestingly, an article just popped-up on this last week: https://www.recall.ai/blog/postgres-postmaster-does-not-scale > > -- > Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ > -- Scott Mead [email protected]
