parallelisation of queries

Hi all.
I am working on the optimization of a simple query and I would like to get more information about the parallel optimisation performed by the DBMS.
My real query is composed of several subqueries connected by ‘union all’ operators, but for the sake of clarity I will discard everything that is not relevant for the understanding and I will reproduce the same “strange” (at least to me) behavior with the following easy example.

Let’s consider a simple table (Test) and the following query:

explain (costs off) select (
    (select count(value) from Test)
    +(select count(value) from Test)
    +(select count(value) from Test)
    +(select count(value) from Test));

I expect that its subqueries (i.e. ‘select count(value) from Test’) are executed in parallel before finally aggregating all the results, but:

1) Even after explicitly setting the correct value of ‘max_parallel_workers_per_gather’ (with ‘force_parallel_mode=On’), the execution time grows linearly over the number of subqueries.
This happens also with a total number of queries that is less than the number of CPUs on my server (and ‘max_parallel_workers_per_gather’ guarantees that there are many available workers);

2) The output of the query, which justifies the aforementioned phenomenon, is reported below.

------------
InitPlan 1                                                
    ->  Finalize Aggregate                                                  
          ->  Gather                                                        
                Workers Planned: 4                                          
                ->  Partial Aggregate                                        
                      ->  Parallel Seq Scan on Test test  |
  InitPlan 2                                               
    ->  Finalize Aggregate                                                  
          ->  Gather                                                        
                Workers Planned: 4                                          
                ->  Partial Aggregate                                        
                      ->  Parallel Seq Scan on Test test_1|
  InitPlan 3                                                
    ->  Finalize Aggregate                                                  
          ->  Gather                                                        
                Workers Planned: 4                                          
                ->  Partial Aggregate                                        
                      ->  Parallel Seq Scan on Test test_2|
  InitPlan 4                                            
    ->  Finalize Aggregate                                                  
          ->  Gather                                                        
                Workers Planned: 4                                          
                ->  Partial Aggregate                                        
                      ->  Parallel Seq Scan on Test test_3|
------------

The output shows that there is one Gather for each subquery. This means that the DBMS decides to run the root query (i.e. the four subqueries) sequentially and then each subquery in parallel with 4 workers.
The “strange” thing is that the DBMS keeps optimising each internal subquery by executing only 4 workers even when the total number of subqueries increases (I tested up to 64 subqueries); in all such cases the number of CPUs on the server is way bigger, so I expect the parallel execution could lead to a further improvement if each subquery is assigned to a worker.
I also guess that the workers do not scale up because the size of the table is constant: in other terms, I think the size of the table limits the speedup that could be achieved in reality when working with an embarrassingly parallel workload.
If my interpretation is correct then, by selecting a specific size of the table, we may even end up in a scenario where only one thread is used for the whole query (i.e. no parallel optimization at all), even though the global workload would justify the execution in parallel on several CPUs.

At this point I have a couple of questions:
1) Is my interpretation correct?
2) Is there a way to “force” the DBMS to dispatch each subquery to a dedicated worker, which would become responsible for it? In other terms, is there a way to use more workers?

Thanks for your support,
I wish you a very good day.

Best regards,
Francesco De Angelis