Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
je lance cette requête sur PG 9.1, j'ai un temps d'execution inacceptable.
Shared_Buffers est à 6GB, work_meme 1GB.
Quelqu'un aurait-il une idéee de comment je pourrais l'améliorer ?
CREATE TEMPORARY TABLE temp_org AS SELECT orgname, id_org
FROM org
WHERE id_org IN (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);
ANALYZE temp_org;
EXPLAIN ANALYZE SELECT ft.id_org
, org_name
, date1
, date_transaction2
, 5
, name
, position
caissier
FROM tab ft, temp_org os
WHERE ft.id_org = os.id_org
AND date1 between '2012-03-01 00:00:00' and '2012-03-31 23:59:59'
AND ft.id_c = 100 ]
Limit (cost=0.00..3258511.90 rows=36997 width=770) (actual time=7.658..7539757.556 rows=39071 loops=1)
-> Nested Loop (cost=0.00..3258511.90 rows=36997 width=770) (actual time=7.657..7539730.757 rows=39071 loops=1)
-> Seq Scan on temp_org os (cost=0.00..1.67 rows=67 width=14) (actual time=0.005..0.123 rows=67 loops=1)
-> Index Scan using table_ndx10 on tab ft (cost=0.00..48627.58 rows=552 width=760) (actual time=190.329..112520.9
35 rows=583 loops=67)
Index Cond: ((id_org = os.id_org) AND (date1 >= '2012-03-01 00:00:00'::timestamp without ti
me zone) AND (date1 <= '2012-03-31 23:59:59'::timestamp without time zone))
Filter: (is_off AND (idc = 196))
Total runtime: 7539780.020 ms
]
La table "tab" contient 234378080 lignes
Dernière modification par Postgres.0 (08/11/2012 15:19:35)
Hors ligne
Il y a 9 autre champs sur les quels je pourais enventuellement filtré, ce qui fait que la décidion de créer des index composé est rès difficile à prendre.
Car si is_off et idc sont dans cet index, ça pourait améliorer la requête mais quid des 9 autres.
Est-ce que je pourrais créer un index composé sur 12 champs ?
Hors ligne
Bonjour,
créer un index sur 12 champs n'est pas forcément une bonne idée, cela augmentera le temps d'insertion dans la table, augmentera la taille de l'index et le rendra moins polyvalent. De plus postgres est capable de combiner plusieurs index.
Quelle est la taille de la table tab ainsi que de l'index table_ndx10 ? Postgres passe presque 2 minutes à rechercher les données dans la table tab, et ce pour chacun des enregistrements de la table temp_org de la jointure. Soit les critères is_off et idc= 196 supprime énormément de lignes (auquel cas des index dessus pourraient aider les choses), soit les données sont accédées trop lentement (pas assez de ram, disque lent .... ?)
Le work_mem est trop élevé, ce qui n'est pas utile pour cette requête.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
La table fait 315 GB et l'index fait 7521 MB
Dernière modification par Postgres.0 (09/11/2012 11:09:47)
Hors ligne
tab est vraiment une table ? pas une vue plutôt ? parce que le plan contient un nœud Limit et je ne vois rien dans votre requête qui explique ce nœud. Si ce n'est pas une vue, dans ce cas, je ne pense pas que la requête correspond au plan indiqué (ou inversement).
Sinon, le temps passé sur l'index est très important. L'avez-vous réindexer récemment ? pouvez-vous le faire ?
Guillaume.
Hors ligne
gleu,
c'est bien lae plan de la requête, et je vous avoue que je ne comprend pas pourquoi y a "LIMIT".
Je vais la reindexer.
Hors ligne
Pages : 1