Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#151 Re : Général » problèmes avec les STAS » 08/08/2012 15:43:01
Qu'est-ce que vous entendez pas "ça ne marche pas" ?
Je veux dire par la que la table retournée est vide.
Voilà les caracteristiques que j'ai pu collecter : work_mem = 1GB
shared_buffers = 8GB
max_connections = 100
maintenance_work_mem = 16MB
effective_cache_size = 16GB
Avec 28GB de RAM.
#152 Re : Général » problèmes avec les STAS » 08/08/2012 15:40:19
CREATE INDEX par_ftransac_2012_03_idxstan
ON aus.par_ftransac_2012_03
USING btree
(stan)
TABLESPACE pg_default;
CREATE INDEX par_ftransac_2012_03_ndx1
ON aus.par_ftransac_2012_03
USING btree
(date_transaction)
TABLESPACE tbl_index;
CREATE INDEX par_ftransac_2012_03_ndx2
ON aus.par_ftransac_2012_03
USING btree
(id_client)
TABLESPACE tbl_index;
CREATE INDEX par_ftransac_2012_03_ndx3
ON aus.par_ftransac_2012_03
USING btree
(id_org)
TABLESPACE tbl_index;
CREATE INDEX par_ftransac_2012_03_ndx5
ON aus.par_ftransac_2012_03
USING btree
(date_transaction_one)
TABLESPACE tbl_index;Voilà les index que j'ai crées, les perfs sont vraiment mauvaises, aidez moi s-il vous plait.
#153 Re : Général » problèmes avec les STAS » 08/08/2012 15:38:27
SELECT ft.id_org
, org_name
, date_transaction
, date_transaction_one
, 5
, merid
, po
, cashier
, currency_code_alpha
, amount
, cashamount
, tipamount
, idref_transaction_type as transaction_type
, is_authorized
, authorization_number
, id_ref_cvm
, transaction_mode
, is_offline
, user_data1
, user_data2
, id_application_db
, id_ref_account_type
, transaction_id
, stan
, rrn
, roc
, em_aid
, em_tc_aac
, em_tvr
, is_reconciled
, original_date_transaction
, original_id_application_db
FROM aus.ftransac ft, org os
WHERE ft.id_org = os.id_org AND
date_transaction BETWEEN '2012-03-01 00:00:00' AND '2012-03-31 23:59:59'
AND ft.id_client = 196
AND ft.id_org = ANY (ARRAY[1686, 1495, 502, 708, 10691, 921, 1219, 707, 704, 1494, 710, 1576, 1536, 1539, 506, 1218, 504, 500, 1540, 1545, 1510, 1217, 1578, 822, 1489, 1530, 1738, 13920, 719, 797, 715, 1506, 1544, 1548, 1114, 1493, 712, 717, 1825, 1523, 713, 923, 1519, 706, 1512, 922, 1524, 1525, 1322, 14901, 711, 1521, 1568, 1811, 1491, 705, 1490, 1533, 1574, 1527, 714, 718, 1488, 709, 1492, 791, 716])
AND cashier = '00000001'
AND is_offline = TRUE ;La table est parttionné par mois, chaque parttion contient en moyene 12000000 d'enregistrements.
#154 Re : Général » problèmes avec les STAS » 08/08/2012 15:23:21
Voilà un plan d'exécution, j'en profite pour vous demander de m'aider à améliorer les perfs de cette requete dont voici le plan
Nested Loop (cost=0.00..4026.82 rows=2 width=2008) (actual time=9558.355..311970.675 rows=39071 loops=1)
-> Append (cost=0.00..4010.26 rows=2 width=1996) (actual time=9531.171..311651.298 rows=39071 loops=1)
-> Seq Scan on ftransac ft (cost=0.00..0.00 rows=1 width=1996) (actual time=0.003..0.003 rows=0 loops=1)
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text) AND (id_org = ANY ('{1686,1495,502,708,10691,921,1219,707,704,1494,710,1576,1536,1539,506,1218,504,500,1540,1545,1510,1217,1578,822,1489,1530,1738,13920,719,797,715,1506,1544,1548,1114,1493,712,717,1825,1523,713,923,1519,706,1512,922,1524,1525,1322,14901,711,1521,1568,1811,1491,705,1490,1533,1574,1527,714,718,1488,709,1492,791,716}'::integer[])))
-> Bitmap Heap Scan on par_ftransac_2012_03 ft (cost=2647.42..4010.26 rows=1 width=1996) (actual time=9531.167..311639.494 rows=39071 loops=1)
Recheck Cond: ((id_client = 196) AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone))
Filter: (is_offline AND ((cashier)::text = '00000001'::text) AND (id_org = ANY ('{1686,1495,502,708,10691,921,1219,707,704,1494,710,1576,1536,1539,506,1218,504,500,1540,1545,1510,1217,1578,822,1489,1530,1738,13920,719,797,715,1506,1544,1548,1114,1493,712,717,1825,1523,713,923,1519,706,1512,922,1524,1525,1322,14901,711,1521,1568,1811,1491,705,1490,1533,1574,1527,714,718,1488,709,1492,791,716}'::integer[])))
-> BitmapAnd (cost=2647.42..2647.42 rows=335 width=0) (actual time=8626.991..8626.991 rows=0 loops=1)
-> Bitmap Index Scan on par_ftransac_2012_03_ndx2 (cost=0.00..1239.89 rows=66956 width=0) (actual time=3930.464..3930.464 rows=11877763 loops=1)
Index Cond: (id_client = 196)
-> Bitmap Index Scan on par_ftransac_2012_03_ndx1 (cost=0.00..1407.28 rows=66956 width=0) (actual time=4166.593..4166.593 rows=13391132 loops=1)
Index Cond: ((date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone))
-> Index Scan using org_pkey on org os (cost=0.00..8.27 rows=1 width=16) (actual time=0.006..0.006 rows=1 loops=39071)
Index Cond: (id_org = ft.id_org)
Total runtime: 311985.884 msje vous rajoute la requete.
#155 Re : Général » problèmes avec les STAS » 08/08/2012 15:01:42
Essayez avec ceci, ça devrait aller mieux :
select * from pg_stats where schemaname='aus' and tablename='par_transaction_2012_03'
ça ne marche pas.
#156 Général » problèmes avec les STAS » 08/08/2012 13:42:28
- Postgres.0
- Réponses : 40
Bonjour,
j'ai de plus en plus de problèmes de performances sur mes tables.
En fait, j'ai une table partitionnée qui contient 13391132 lignes
Quand je faits select * from pg_stats where tablename='aus.par_transaction_2012_03';
j'ai le resultat suivant :
schemaname | tablename | attname | inherited | null_frac | avg_width | n_distinct | most_common_vals | most_common_freqs | histogram_bounds | correlation
------------+-----------+---------+-----------+-----------+-----------+------------+------------------+-------------------+------------------+-------------
(0 rows)Est-ce-que ça explique les problèmes de performances que j'ai.
Comment je peux faire pour que cette requete me retourne un tableau qui contient des données.
Merci
#157 Général » Problème avec les Indexs » 06/08/2012 13:48:48
- Postgres.0
- Réponses : 2
Supposons que j'ai une requête de la forme suivante : select * from table where champ1 = value1 And champ2=value2;
Supposons que je dispose d'un index idx1 sur le champ1 et d'un index idx2 sur le champ 2.
Pour quoi postgres n'utilise qu'un seul des deux indexes pour executer la requete.
Comment pourrais-je faire pour qu'il utilise les deux indexs.
Supposons que j'ai rajouté un troisieme index composé idx3(champ1, champ2), pour quoi faut-il supprimer idx1 et idx2 pour que idx3 soit utilisé.
Supposons que je dispose d'une table parttionnée, pourquoi devrait-je avoir les memes index sur les partitions que sur la table chapeau (mère).
Comment je peux dire à postgres d'utiliser les index B-tree et pas les bit-map et vice versa.
Merci
#158 Re : Général » HashAggregate to slow » 01/08/2012 17:26:02
Merci bcp gleu
#159 Re : Général » HashAggregate to slow » 01/08/2012 16:58:57
Merci beaucoup rjuju
quelle est donc la structure de donnée qui correspond au bitmap.
#160 Re : Général » HashAggregate to slow » 01/08/2012 14:03:29
Cette solution ne fonctionne pas avec PostgreSQL. Avant la version 9.2 (en beta depuis deux semaines), PostgreSQL est obligé de lire l'index et la table lors d'un parcours d'index, quelque soit ce parcours d'index (Index Scan ou Bitmap Index Scan).
Bonjour gleu,
serait-il possible de m'expliquer ce que vous voulez dire par la.
Si PG est obligé de lire la table et l'index, à qoui sert donc de faire un index scan, pour quoi pas un seq scan.
Y a t-il d'autre SGBD qui ne lisent pas la table et l'index lors d'un index scan, comment font ils?
quelle difference y a t-il entre Index Scan et Bitmap index Scan?
J'ai cru comprendre que lors de Bitmap PG trie les adresses physiques des bloques avant d'aller chercher les lignes de la tables, pouvez m'expliquer en detail.
Merci
#161 Re : Général » deadlock detected » 03/07/2012 15:29:58
Merci beaucoup,
j'ai opté finalement pour des écritures sequentielles.
#162 Re : Général » deadlock detected » 03/07/2012 14:51:26
on ne peut pas paralléliser suivant les lignes de la table A, les deux process doivent chacun lire toutes les lignes de cette table.
ce que je me demande c'est :
si je faits LOCK TABLE A IN SHARE ROW EXCLUSIVE MODE
1. Est-ce-que une autre transaction peut écrire dans la table A.
2. Est-ce-que une autre transaction peut lire les lignes de la table A
3. est-ce-que toute la table est verouillée ou bien seules les lignes updatées par ma transaction sont verouillées.
4. En quoi les perfs sont impactées (exemple????).
#163 Re : Général » deadlock detected » 03/07/2012 11:10:41
flo:
les transactions sont parallèles pour des raisons de perfs.
#164 Re : Général » deadlock detected » 03/07/2012 10:31:23
Je connais pas bien les LOCK et compagnie.
Mais y a pas quelque chose genre LOCK TABLE A IN SHARE ROW EXCLUSIVE MODE qui me permet de faire ces taches correctement.
#165 Re : Général » deadlock detected » 03/07/2012 10:28:42
Oui le ";" est une erreur de frappe.
Ces deux updates sont chacun dans un fichier et chacun est suivi d'un "commit".
Manque de bole, ils update en meme temps les memes lignes de la table A.
#166 Re : Général » deadlock detected » 03/07/2012 10:26:43
je dois executer deux transaction en parallèle.
Ces transactions insèrent dans des tables differentes (B et C).
A la fin de chanque transaction , je dois taguer des lignes d'une meme table.
Ce tague veut dire que les lignes de la table A ont été bien insérées
#167 Re : Général » deadlock detected » 03/07/2012 09:23:46
Update table A
SET A.a = 1
WHERE 0 <= id < 1000;
Update table A
SET A.b = 1
WHERE 0 <= id < 1000;
#168 Général » deadlock detected » 02/07/2012 16:43:59
- Postgres.0
- Réponses : 14
Bonjour,
J'essaye de faire deux updates paralléle sur la même table, j'ai bien évidamment un problème avec les lock.
psql:ag_update_c4.sql:2132: ERROR: deadlock detected
DETAIL: Process 21448 waits for ShareLock on transaction 8105608; blocked by process 21447.
Process 21447 waits for ShareLock on transaction 8105610; blocked by process 21448.
HINT: See server log for query details.
ROLLBACK
.Quelequ'un sait comment faire pour executer convenablement mes deux ubdates.
Je note que pour chaque update, je suis obligatoirement en single transaction.
Je suis sur la 9.1.
Cordialement
#169 Re : Général » HashAggregate to slow » 29/05/2012 15:34:51
Le CLUSTER ne marche pas chez moi, pourtant je suis ssur la 9.1.
Peut-être que c'est par ce que ma table est une partition!
#170 Re : Général » HashAggregate to slow » 29/05/2012 15:01:01
dverite
peus-tu expliquer un oeu plus le CLUSTER,
et quelles sont les commandes pour faire un REINDEX et un CLUSTER.
#171 Re : Général » HashAggregate to slow » 29/05/2012 14:57:50
Petite question :
Ces clauses WHERE peuvent changer ?
la reponse est oui!
#172 Re : Général » HashAggregate to slow » 29/05/2012 11:32:50
Bonjour,
le BETWEEN n'est pas possible, je suis obligé d'enumerer tous les id.
J'ai un index sur le id, sur le id_org, j'ai aussi un index sur (id_org, id_ref, ag_date, id).
La solution qui consiste à créer un index sur aft (id_org, id_ref, ag_date, id, p,am_c, am_co, am_p, am_pw, am_r, am_s, am_s_n, am_t, nb_of_c, nb_of_c_s, nb_of_co, nb_of_p, nb_of_pw, nb_of_r, nb_of_sale, nb_of_sale_n, nbr_of_c) a été écartée depuis longtemps.
J'avais fait des tests pour comparer les performances entre IN et ANY et je n'ai pas vu de difference.
Merci beaucoup
#173 Re : Général » HashAggregate to slow » 29/05/2012 11:04:50
Bonjour,
le BETWEEN n'est pas possible, je suis obligé d'enumerer tous les id.
J'ai un index sur le id, sur le id_org, j'ai aussi un index sur (id_org, id_ref, ag_date, id).
La solution qui consiste de créer un insex sur aft (id_org, id_ref, ag_date, id, p,am_c, am_co, am_p, am_pw, am_r, am_s, am_s_n, am_t, nb_of_c, nb_of_c_s, nb_of_co, nb_of_p, nb_of_pw, nb_of_r, nb_of_sale, nb_of_sale_n, nbr_of_c) a été écarter depuis longtemps.
J'avais fait des tests pour comparer les performances entre IN et ANY et je n'ai pas vu de difference.
Merci beaucoup.
#174 Re : Général » HashAggregate to slow » 25/05/2012 15:09:26
et que veux dire donc
(actual time=9869.904..9869.912 ), quel est le lien avec le cout que vous avez expliquer plus haut.
Comment savez vous que
"Le cout initial est hérité du IndexScan (8.84) qui s'exécute entièrement avant le HashAggregate"
Pensez vous qu'il est mieux d'utiliser les fonctions analytiques.
Pour la configuration du serveur, je ne sais comment la trouver.
#175 Re : Général » HashAggregate to slow » 25/05/2012 14:19:57
En fait le HashAggregate ne prend presque pas de temps sur cet explain, il a un cost de 0.03 et un temps plus que négligeable.
C'est le IndexScan qui prend presque tout le temps d'exécution.
L'explain que vous montrez ici est très rapide, quand vous dites que chez vous il prend 10 secondes, c'est sur un serveur différent ?
Qu'exst ce que je peux faire pour améliorer le comportement du index scan?
Merci