From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Marc SCHAEFER <alphanet-postgresql-general(at)alphanet(dot)ch> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Naive question about multithreading/multicore |
Date: | 2024-10-12 19:16:04 |
Message-ID: | CA+hUKG+bjgdh7APFCC_8cZKnMzeagYjiEqTp+qn2koafGmi1aQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Oct 13, 2024 at 6:31 AM Marc SCHAEFER
<alphanet-postgresql-general(at)alphanet(dot)ch> wrote:
> template1=> 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 = 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 | Date | Subject | |
---|---|---|---|
Next Message | Koen De Groote | 2024-10-12 20:33:16 | Using FDW to connect to a more recent postgres version? |
Previous Message | Koen De Groote | 2024-10-12 18:32:04 | Re: Foreign Data Wrapper behavior? |