PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 17/05/2016 11:28:43

uruvela
Membre

9.6beta1 et parallelisme

Salut, je me suis lancé dans qques tests avec la beta1. Pour être certain de bien comprendre la philosophie du truc, j'ai des questions.


1) max_parallel_degree est par défaut à 2 et ne peut pas dépasser la valeur de max_worker_processes. Donc ça veut dire que de base, on utilise 1 + 2 cœurs pour traiter une  requête qui rentre dans le scope (agrégat, jointure ou parcours séquentiel)  ?


2) l'optimiseur décide de lui même d'une limite du degrés même si max_parallel_degree indique une valeur plus haute (en fonction du nombre des lignes à parcourir par exemple) ?


Merci !

Dernière modification par uruvela (17/05/2016 12:38:54)

Hors ligne

#2 17/05/2016 12:31:25

rjuju
Administrateur

Re : 9.6beta1 et parallelisme

Bonjour,

1)  Il est par défaut à 2 le temps de la beta.  Il est probable qu'il repasse par défaut à 0 pour la version finale. Sinon, oui pour exécuter une requête paralèlle, des workers seront utilisés, pris dans le pool de max_worker_process. Vous pouvez techniquement mettre une valeut max_parallel_degree beaucoup plus élevée que max_workers_process, dans les fait il ne pourra pas y avoir plus de max_worker_process processus utilisés pour une requête parallèle.  Ce paramètre indique le nombre de processus supplémentaires qui peuvent être lancés, donc oui cela fera 1 (le nœud gather) + 2 (les parallel workers) processus utilisés pour traiter une requête de manière parallèle. Attention, il s'agit d'une limite globale, si vous lancez plusieurs requêtes en même temps, il ne pourra pas y avoir plus de 2 parallel worker à un instant donné.


2) Oui, il décide tout seul du nombre de workers à utiliser, en fonction de la taille de chaque objet. Vous pouvez sinon spécifier un parallel_worker par objet (ALTER TABLE mon_objet SET (parallel_degree = 2) par exemple). Les paramètres  parallel_setup_cost et parallel_tuple_cost influent également sur le choix d'un plan parallèle ou non.

Hors ligne

#3 17/05/2016 13:09:13

uruvela
Membre

Re : 9.6beta1 et parallelisme

Merci Julien.

Hors ligne

#4 19/05/2016 13:48:23

Re : 9.6beta1 et parallelisme

Quelques tests probants avec la 9.6 beta  - il y a 7 workers
select count(*) from PSOSANTECL_X10 (table sans index)

Total query runtime: 3.4 secs
1 ligne récupérée.

105807216 records

Plan d'accès :
explain select count(*) from PSOSANTECL_X10

"Finalize Aggregate  (cost=1812523.34..1812523.35 rows=1 width=8)"
"  ->  Gather  (cost=1812522.61..1812523.32 rows=7 width=8)"
"        Workers Planned: 7"
"        ->  Partial Aggregate  (cost=1811522.61..1811522.62 rows=1 width=8)"
"              ->  Parallel Seq Scan on psosantecl_x10  (cost=0.00..1774778.89 rows=14697489 width=0)"

Mais mieux encore :

select PSOSNUMOPE, sum(psosnopart)
from PSOSANTECL_X10
group by PSOSNUMOPE
order by PSOSNUMOPE;


Total query runtime: 7.8 secs
1936 lignes récupérées.

explain select PSOSNUMOPE, sum(psosnopart)
from PSOSANTECL_X10
group by PSOSNUMOPE
order by PSOSNUMOPE;

"Finalize GroupAggregate  (cost=1849331.51..1849335.51 rows=64 width=12)"
"  Group Key: psosnumope"
"  ->  Sort  (cost=1849331.51..1849332.63 rows=448 width=12)"
"        Sort Key: psosnumope"
"        ->  Gather  (cost=1849266.34..1849311.78 rows=448 width=12)"
"              Workers Planned: 7"
"              ->  Partial HashAggregate  (cost=1848266.34..1848266.98 rows=64 width=12)"
"                    Group Key: psosnumope"
"                    ->  Parallel Seq Scan on psosantecl_x10  (cost=0.00..1774778.89 rows=14697489 width=6)"

Paramètres utilisés dans postgres.conf
max_parallel_degree = 16             # max number of worker processes per node
max_worker_processes = 16            # (change requires restart)

Hors ligne

#5 23/05/2016 13:38:40

uruvela
Membre

Re : 9.6beta1 et parallelisme

Alors pour tout ce qui est agrégat et parcours séquentiel les résultats sont bons, par contre les jointures c'est chelou :



postgres@test(5436)=# explain (analyze,buffers) select count(test.id) from test,test2 where test.id=test2.id;
                                                                       QUERY PLAN                                                                       
---------------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate  (cost=7531042.51..7531042.52 rows=1 width=8) (actual time=596587.637..596587.638 rows=1 loops=1)
   Buffers: shared hit=6913140 read=2223271, temp read=2472358 written=2472118
   ->  Gather  (cost=7531041.78..7531042.49 rows=7 width=8) (actual time=594491.748..596587.626 rows=8 loops=1)
         Workers Planned: 7
         Workers Launched: 7
         Buffers: shared hit=6913140 read=2223271, temp read=2472358 written=2472118
         ->  Partial Aggregate  (cost=7530041.78..7530041.79 rows=1 width=8) (actual time=591358.147..591358.147 rows=1 loops=8)
               Buffers: shared hit=6912526 read=2223248, temp read=2472358 written=2472118
               ->  Hash Join  (cost=3655625.68..7280042.26 rows=99999808 width=4) (actual time=279934.425..590439.429 rows=12500000 loops=8)
                     Hash Cond: (test.id = test2.id)
                     Buffers: shared hit=6912526 read=2223248, temp read=2472358 written=2472118
                     ->  Parallel Seq Scan on test  (cost=0.00..1157898.14 rows=14285714 width=4) (actual time=123.782..59470.614 rows=12500000 loops=8)
                           Buffers: shared hit=1 read=1015040
                     ->  Hash  (cost=2015003.08..2015003.08 rows=99999808 width=4) (actual time=279717.783..279717.783 rows=100000000 loops=8)
                           Buckets: 16777216  Batches: 16  Memory Usage: 350698kB
                           Buffers: shared hit=6911850 read=1208190, temp written=2197272
                           ->  Seq Scan on test2  (cost=0.00..2015003.08 rows=99999808 width=4) (actual time=12.675..168122.057 rows=100000000 loops=8)
                                 Buffers: shared hit=6911850 read=1208190
Planning time: 268.188 ms
Execution time: 596680.899 ms
(20 lignes)



postgres@test(5436)=# set max_parallel_degree=0  ;
SET


postgres@test(5436)=# explain (analyze,buffers) select count(test.id) from test,test2 where test.id=test2.id;
                                                                         QUERY PLAN                                                                         
------------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=7958443.01..7958443.02 rows=1 width=8) (actual time=130162.321..130162.321 rows=1 loops=1)
   Buffers: shared hit=1256 read=1560237
   ->  Merge Join  (cost=306.68..7708443.49 rows=99999808 width=4) (actual time=11.300..123623.124 rows=100000000 loops=1)
         Merge Cond: (test.id = test2.id)
         Buffers: shared hit=1256 read=1560237
         ->  Index Only Scan using test_pkey on test  (cost=0.57..2596776.57 rows=100000000 width=4) (actual time=11.285..12428.427 rows=100000000 loops=1)
               Heap Fetches: 0
               Buffers: shared hit=4 read=273256
         ->  Index Only Scan using test2_pkey on test2  (cost=0.57..3611781.69 rows=99999808 width=4) (actual time=0.011..84640.565 rows=100000000 loops=1)
               Heap Fetches: 100000000
               Buffers: shared hit=1252 read=1286981
Planning time: 75.299 ms
Execution time: 130162.364 ms

Hors ligne

Pied de page des forums