Re: Naive question about multithreading/multicore
От | Thomas Munro |
---|---|
Тема | Re: Naive question about multithreading/multicore |
Дата | |
Msg-id | CA+hUKG+bjgdh7APFCC_8cZKnMzeagYjiEqTp+qn2koafGmi1aQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Naive question about multithreading/multicore (Marc SCHAEFER <alphanet-postgresql-general@alphanet.ch>) |
Ответы |
Re: Naive question about multithreading/multicore
|
Список | pgsql-general |
On Sun, Oct 13, 2024 at 6:31 AM Marc SCHAEFER <alphanet-postgresql-general@alphanet.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.
В списке pgsql-general по дате отправления: