Re: optimizing number of workers

if I "alter table allwise set (parallel_workers = 64);" then I can get 64
workers. I wonder if the code
to check the rel_parallel_workers do deal with the default algorithm not
allocating sufficient
parallel_workers.

On Mon, Jul 14, 2025 at 2:54 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Greg Hennessy <greg(dot)hennessy(at)gmail(dot)com> writes:
> >> Postgres has chosen to use only a small fraction of the CPU's I have on
> >> my machine. Given the query returns an answer in about 8 seconds, it
> may be
> >> that Postgresql has allocated the proper number of works. But if I
> wanted
> >> to try to tweak some config parameters to see if using more workers
> >> would give me an answer faster, I don't seem to see any obvious knobs
> >> to turn. Are there parameters that I can adjust to see if I can increase
> >> throughput? Would adjusting parallel_setup_cost or parallel_tuple_cost
> >> likely to be of help?
>
> See the bit about
>
> * Select the number of workers based on the log of the size of
> * the relation. This probably needs to be a good deal more
> * sophisticated, but we need something here for now. Note
> that
>
> in compute_parallel_worker(). You can move things at the margins by
> changing min_parallel_table_scan_size, but that logarithmic behavior
> will constrain the number of workers pretty quickly. You'd have to
> change that code to assign a whole bunch of workers to one scan.
>
> (No, I don't know why it's done like that. There might be related
> discussion in our archives, but finding it could be difficult.)
>
> regards, tom lane
>