public inbox for [email protected]  
help / color / mirror / Atom feed
From: Greg Hennessy <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: optimizing number of workers
Date: Tue, 15 Jul 2025 13:07:44 -0400
Message-ID: <CA+mZaON_Ku7tfC-oX=tRX+PaD-dpo_FTEhXFi_FjGaGb2Ed0gw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CA+mZaOMbOTUrs1QXWKyaxLfWGM2N21dQ=72GRx6jodALL-r4aQ@mail.gmail.com>
	<IA3PR10MB811375110A03F754BA29A0048D4BA@IA3PR10MB8113.namprd10.prod.outlook.com>
	<CA+mZaOMRBe4_szsyD-JVTQJ25ah6tOUdE_923ZffT-9zVjxqtQ@mail.gmail.com>
	<[email protected]>

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 <[email protected]> wrote:

> Greg Hennessy <[email protected]> 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
>


view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: optimizing number of workers
  In-Reply-To: <CA+mZaON_Ku7tfC-oX=tRX+PaD-dpo_FTEhXFi_FjGaGb2Ed0gw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox