From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Hennessy <greg.hennessy@gmail.com>
cc: "Weck, Luis" <luis.weck@pismo.io>,
        "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Subject: Re: optimizing number of workers
In-reply-to: <CA+mZaOMRBe4_szsyD-JVTQJ25ah6tOUdE_923ZffT-9zVjxqtQ@mail.gmail.com>
References: <CA+mZaOMbOTUrs1QXWKyaxLfWGM2N21dQ=72GRx6jodALL-r4aQ@mail.gmail.com> <IA3PR10MB811375110A03F754BA29A0048D4BA@IA3PR10MB8113.namprd10.prod.outlook.com> <CA+mZaOMRBe4_szsyD-JVTQJ25ah6tOUdE_923ZffT-9zVjxqtQ@mail.gmail.com>
Comments: In-reply-to Greg Hennessy <greg.hennessy@gmail.com>
	message dated "Mon, 14 Jul 2025 14:25:19 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <710282.1752519282.1@sss.pgh.pa.us>
Date: Mon, 14 Jul 2025 14:54:42 -0400
Message-ID: <710283.1752519282@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/710283.1752519282%40sss.pgh.pa.us>
Precedence: bulk

Greg Hennessy <greg.hennessy@gmail.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