MIME-Version: 1.0
References: <CA+mZaOMbOTUrs1QXWKyaxLfWGM2N21dQ=72GRx6jodALL-r4aQ@mail.gmail.com>
 <IA3PR10MB811375110A03F754BA29A0048D4BA@IA3PR10MB8113.namprd10.prod.outlook.com>
 <CA+mZaOMRBe4_szsyD-JVTQJ25ah6tOUdE_923ZffT-9zVjxqtQ@mail.gmail.com> <710283.1752519282@sss.pgh.pa.us>
In-Reply-To: <710283.1752519282@sss.pgh.pa.us>
From: Greg Hennessy <greg.hennessy@gmail.com>
Date: Tue, 15 Jul 2025 13:07:44 -0400
Message-ID: <CA+mZaON_Ku7tfC-oX=tRX+PaD-dpo_FTEhXFi_FjGaGb2Ed0gw@mail.gmail.com>
Subject: Re: optimizing number of workers
Cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000cdbced0639fad2f1"
Archived-At: <https://www.postgresql.org/message-id/CA%2BmZaON_Ku7tfC-oX%3DtRX%2BPaD-dpo_FTEhXFi_FjGaGb2Ed0gw%40mail.gmail.com>
Precedence: bulk

--000000000000cdbced0639fad2f1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

if I "alter table allwise set (parallel_workers =3D 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=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Greg Hennessy <greg.hennessy@gmail.com> writes:
> >> Postgres has chosen to use only a small fraction of the CPU's I have o=
n
> >> 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 increa=
se
> >> 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
>

--000000000000cdbced0639fad2f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">if I &quot;alter table allwise set (parallel_workers =3D 6=
4);&quot; then I can get 64 workers. I wonder if the code<div>to check the =
rel_parallel_workers do deal with the default algorithm not allocating suff=
icient</div><div>parallel_workers.</div><div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, Jul 14, 2025 at 2:54=E2=80=AFPM Tom Lane &lt;<a href=3D"mailto:tg=
l@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Greg Hennessy &lt;<a href=3D"mailto:greg.=
hennessy@gmail.com" target=3D"_blank">greg.hennessy@gmail.com</a>&gt; write=
s:<br>
&gt;&gt; Postgres has chosen to use only a small fraction of the CPU&#39;s =
I have on<br>
&gt;&gt; my machine. Given the query returns an answer in about 8 seconds, =
it may be<br>
&gt;&gt; that Postgresql has allocated the proper number of works. But if I=
 wanted<br>
&gt;&gt; to try to tweak some config parameters to see if using more worker=
s<br>
&gt;&gt; would give me an answer faster, I don&#39;t seem to see any obviou=
s knobs<br>
&gt;&gt; to turn. Are there parameters that I can adjust to see if I can in=
crease<br>
&gt;&gt; throughput? Would adjusting parallel_setup_cost or parallel_tuple_=
cost<br>
&gt;&gt; likely to be of help?<br>
<br>
See the bit about<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Select the number of work=
ers based on the log of the size of<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* the relation.=C2=A0 This =
probably needs to be a good deal more<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* sophisticated, but we nee=
d something here for now.=C2=A0 Note that<br>
<br>
in compute_parallel_worker().=C2=A0 You can move things at the margins by<b=
r>
changing min_parallel_table_scan_size, but that logarithmic behavior<br>
will constrain the number of workers pretty quickly.=C2=A0 You&#39;d have t=
o<br>
change that code to assign a whole bunch of workers to one scan.<br>
<br>
(No, I don&#39;t know why it&#39;s done like that.=C2=A0 There might be rel=
ated<br>
discussion in our archives, but finding it could be difficult.)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div>

--000000000000cdbced0639fad2f1--