Subject: Naive question about multithreading/multicore

From: Marc SCHAEFER <[email-masked]>
Date: Sat, 12 Oct 2024 19:30:58 +0200

Hello,

on a machine where starting two processes:
   perl -e 'while (1) { ; }'
I see two processed at 100% CPU, which is expected (with top).

Now, if I do:

template1=> SELECT COUNT(*) FROM pg_class a, pg_class b, pg_class c;

I see only one 100% CPU PostgreSQL process.

I read that while PostgreSQL connetions lead to a UNIX process model,
which is better for isolation, some operations have been parallelized
and can use more than one core/thread.

Maybe this specific case was not (yet?) parallelized, or should it
be and thus something is issing in my configuration?

Thank you.

PS: psql (13.16 (Debian 13.16-0+deb11u1))

---

From: Thomas Munro <[email-masked]>
Date: Sun, 13 Oct 2024 08:16:04 +1300

> I see only one 100% CPU PostgreSQL process.

If you set set min_parallel_table_scan_size = 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.

---

From: Marc SCHAEFER <[email-masked]>
Date: Mon, 14 Oct 2024 09:30:07 +0200

Hello,

> If you set set min_parallel_table_scan_size = 0 then it uses

Without it, it uses one CPU and takes about 8.5 s (count is 57512456).

With it, it is indeed parallel (multiple CPU used) and it takes about 6s.

As this is on a machine with slow disks, it is perfectly ok, I just
wanted to see the CPU parallelism in action.

Thank you!