Vous n'êtes pas identifié(e).
Pages : 1
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 ;
SETpostgres@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
Merci Julien.
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 !
ça doit donner qque chose comme 8Go+swap utilisable par les applications dans la vm. Vous pouvez essayer de monter le ratio de 50 à 75.
Comme c'est une VM, qu'avez vous comme valeur pour vm.overcommit_memory & vm.overcommit_ratio ?
J'avoue ne pas bien comprendre : vous parlez bien de SQL server ou c'est un lapsus ?
La 8.4 n'est plus supportée depuis juillet 2014.
Si effectivement le temps de réponse est un problème, il faudrait envisager une autre solution comme de récupérer les données distantes via un ETL pour les avoir en local (en fonction de vos usages bien sur).
Est-ce possible de nous donner la valeur du log_line_prefix du fichier postgresql.conf ?
De plus, lancez-vous pgbadger avec l'option --prefix ou non ?
C'est une blague là ?
Ok, j'ai donc recommencé avec 5 EXECUTE derrière un PREPARE et pas de loadbalancing ce qui semble confirmer que comme un prepare statement n'est jamais loadbalancé les EXECUTE ne le sont pas non plus derrière.
Merci encore pour l'éclairage.
Ah oui effectivement,merci . C'est donc toujours le cas pour une instructions préparée puisqu'elle n'existe que dans la session en cours et ne peut donc être exécutée que dans celle-ci ?
Bonjour, j'ai deux serveurs (9.1)en streaming replication,le deuxième est en hot standby. J'utilise la 3.2.1 de pgpool.
Je ne m'étais jamais trop posé la question de comment travaille le parser, et je viens d'étudier la logique du loadbalancing : http://www.pgpool.net/docs/latest/where … ueries.pdf .
J'ai fait qques tests que je n'arrive pas à comprendre :
1) Avec une requête du type "SELECT x,y,z FROM A limit 2", je la lance 100x (dans un script qui ouvre une connexion à chaque itération) : 50 vont sur le noeud 1 et 50 sur le noeud 2.
2) Avec une requête du "PREPARE toto(int) as SELECT x,y,z FROM A limit $1; execute toto(2)", je la lance 100x : les 100 partent sur le noeud 1.
J'avais l'impression en lisant le schéma de conditionnement, qu'il allait parser la requête dans le prepare et pourtant ça ne semble pas être le cas.
Je me trompe en lisant le schéma ? (je penche plutôt là dessus)
J'ai un loupé dans ma configuration du pgpool ?
Ok je note aussi ce point. Merci.
Oui effectivement,c'est vrai qu'on peut décider de le positionner directement au dessus pour gagner du temps. Merci.
Salut à tous, j'ai du mal à trouver une règle claire pour établir cette valeur. Dans le cas d'un streaming entre 1 maitre et 1 esclave (en 9.1.2) et si je pense bien comprendre la doc : il faut que max_wal_senders soit à 1 dans ce cas ? Est ce qu'il y a un intérêt à mettre une valeur supérieure ?
Merci !
Cf doc :
max_wal_senders (integer)
Indique le nombre maximum de connexions concurrentes à partir des serveurs en attente ou des clients en mode sauvegarde de base par le flux de réplication (c'est-à-dire le nombre maximum de processus walsender connectés en même temps). La valeur par défaut est zéro. Ce paramètre peut seulement être configuré au lancement du serveur. wal_level doit être configuré à archive ou hot_standby pour permettre les connexions des serveurs en attente.
Pages : 1
