MIME-Version: 1.0
References: <ZwqyUjoXsrPg55vA@alphanet.ch>
In-Reply-To: <ZwqyUjoXsrPg55vA@alphanet.ch>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sun, 13 Oct 2024 08:16:04 +1300
Message-ID: <CA+hUKG+bjgdh7APFCC_8cZKnMzeagYjiEqTp+qn2koafGmi1aQ@mail.gmail.com>
Subject: Re: Naive question about multithreading/multicore
To: Marc SCHAEFER <alphanet-postgresql-general@alphanet.ch>
Cc: pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKG%2Bbjgdh7APFCC_8cZKnMzeagYjiEqTp%2Bqn2koafGmi1aQ%40mail.gmail.com>
Precedence: bulk

On Sun, Oct 13, 2024 at 6:31=E2=80=AFAM Marc SCHAEFER
<alphanet-postgresql-general@alphanet.ch> wrote:
> template1=3D> SELECT COUNT(*) FROM pg_class a, pg_class b, pg_class c;
>
> I see only one 100% CPU PostgreSQL process.

If you set set min_parallel_table_scan_size =3D 0 then it uses
parallelism, and completes much faster.  The planner generally works
by comparing the estimated cost of various plans (it is a "cost based"
optimiser), but the decision to actually consider parallelism at all
is essentially "rule based", and the rules aren't smart enough for
this query with default settings.  pg_class is considered too small to
bother parallelising the scan, and here you have a 3-way cross-join
which generates an enormous of work for each tuple so it is actually
a good idea to parallelise it.  I guess people don't actually do that too
often.