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 29/12/2010 12:54:46

arthurr
Membre

tables partitionnées - Perf avant ANALYSE

Bonjour,

Je travaille sur la migration d'une base Postgresql de 50 go d'une version 8.2 vers une version 9.0.2 .
Les serveurs sont sous GNU/Linux.

J'ai fait un dump sur l'ancien serveur puis un restore sur le nouveau serveur, j'avais desactivé autovacuum et fsync pour gagner du temps.

Suite au restore, j'ai voulu tester une requete avant de relancer notre ami autovacuum (j'ai oublie le analyse) :
GroupAggregate  (cost=2860395.86..2897600.62 rows=992127 width=23)
   ->  Sort  (cost=2860395.86..2862876.18 rows=992127 width=23)
         Sort Key: sources.name, public.documents.dav, public.documents.id_fourniture, public.documents.id_source
         ->  Nested Loop  (cost=0.00..2761579.19 rows=992127 width=23)
               Join Filter: (public.documents.id_source = sources.id)
               ->  Seq Scan on sources  (cost=0.00..28.50 rows=6 width=9)
                     Filter: (name = ANY ('{S060,S139,S141,S187,S186,S117}'::text[]))
               ->  Append  (cost=0.00..437319.82 rows=1835090 width=18)
                     ->  Seq Scan on documents  (cost=0.00..18.25 rows=220 width=18)
                           Filter: (public.documents.dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_a_id_source_dav on documents_a documents  (cost=0.00..14308.52 rows=85313 width=18)
                           Index Cond: ((public.documents.id_source = sources.id) AND (public.documents.dav >= '2010-11-01'::date))
                     ->  Index Scan using idx_documents_b_id_source_dav on documents_b documents  (cost=0.00..15929.87 rows=85869 width=18)
                           Index Cond: ((public.documents.id_source = sources.id) AND (public.documents.dav >= '2010-11-01'::date))
                     ->  Index Scan using idx_documents_c_id_source_dav on documents_c documents  (cost=0.00..20128.58 rows=68490 width=18)
                           Index Cond: ((public.documents.id_source = sources.id) AND (public.documents.dav >= '2010-11-01'::date))
                     ->  Index Scan using idx_documents_d_id_source_dav on documents_d documents  (cost=0.00..20569.58 rows=26634 width=18)
                           Index Cond: ((public.documents.id_source = sources.id) AND (public.documents.dav >= '2010-11-01'::date))
                     ->  Bitmap Heap Scan on documents_e documents  (cost=2836.16..163357.52 rows=243515 width=18)
                           Recheck Cond: (public.documents.id_source = sources.id)
                           Filter: (public.documents.dav >= '2010-11-01'::date)
                           ->  Bitmap Index Scan on idx_documents_e_id_source_nod  (cost=0.00..2815.87 rows=243515 width=0)
                                 Index Cond: (public.documents.id_source = sources.id)
                     ->  Index Scan using idx_documents_f_dav on documents_f documents  (cost=0.00..49455.30 rows=1096600 width=18)
                           Index Cond: (public.documents.dav >= '2010-11-01'::date)
                     ->  Bitmap Heap Scan on documents_z documents  (cost=2661.28..153552.21 rows=228449 width=18)
                           Recheck Cond: (public.documents.id_source = sources.id)
                           Filter: (public.documents.dav >= '2010-11-01'::date)
                           ->  Bitmap Index Scan on idx_documents_z_id_source_nod  (cost=0.00..2642.25 rows=228449 width=0)
                                 Index Cond: (public.documents.id_source = sources.id)

Les resultats sortent en 568,088 ms ms !!!

Apres le ANALYSE :

GroupAggregate  (cost=1333649.49..1338489.35 rows=129063 width=23) (actual time=5845.206..5845.521 rows=9 loops=1)
   ->  Sort  (cost=1333649.49..1333972.15 rows=129063 width=23) (actual time=5845.133..5845.209 rows=608 loops=1)
         Sort Key: sources.name, public.documents.dav, public.documents.id_fourniture, public.documents.id_source
         Sort Method:  quicksort  Memory: 72kB
         ->  Hash Join  (cost=13.37..1322693.52 rows=129063 width=23) (actual time=4340.964..5843.228 rows=608 loops=1)
               Hash Cond: (public.documents.id_source = sources.id)
               ->  Append  (cost=0.00..1305256.70 rows=4302086 width=18) (actual time=638.425..5114.612 rows=4301197 loops=1)
                     ->  Seq Scan on documents  (cost=0.00..18.25 rows=220 width=18) (actual time=0.003..0.003 rows=0 loops=1)
                           Filter: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_a_id_source_dav on documents_a documents  (cost=0.00..157602.71 rows=85313 width=18) (actual time=638.420..677.528 rows=85585 loops=1)
                           Index Cond: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_b_id_source_dav on documents_b documents  (cost=0.00..175749.59 rows=85869 width=18) (actual time=401.847..441.437 rows=86158 loops=1)
                           Index Cond: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_c_id_source_dav on documents_c documents  (cost=0.00..227966.18 rows=205470 width=18) (actual time=302.108..478.644 rows=204141 loops=1
)
                           Index Cond: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_d_id_source_dav on documents_d documents  (cost=0.00..282219.40 rows=133172 width=18) (actual time=94.011..636.103 rows=130852 loops=1)
                           Index Cond: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_e_dav on documents_e documents  (cost=0.00..205258.12 rows=1056961 width=18) (actual time=0.026..549.146 rows=1078171 loops=1)
                           Index Cond: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_f_dav on documents_f documents  (cost=0.00..48663.07 rows=1096600 width=18) (actual time=0.029..571.607 rows=1103663 loops=1)
                           Index Cond: (dav >= '2010-11-01'::date)
                     ->  Index Scan using idx_documents_z_dav on documents_z documents  (cost=0.00..207779.38 rows=1638481 width=18) (actual time=0.025..924.170 rows=1612627 loops=1)
                           Index Cond: (dav >= '2010-11-01'::date)
               ->  Hash  (cost=13.29..13.29 rows=6 width=9) (actual time=0.098..0.098 rows=6 loops=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 1kB
                     ->  Bitmap Heap Scan on sources  (cost=7.55..13.29 rows=6 width=9) (actual time=0.084..0.091 rows=6 loops=1)
                           Recheck Cond: (name = ANY ('{S060,S139,S141,S187,S186,S117}'::text[]))
                           ->  Bitmap Index Scan on idx_sources_name  (cost=0.00..7.55 rows=6 width=0) (actual time=0.072..0.072 rows=6 loops=1)
                                 Index Cond: (name = ANY ('{S060,S139,S141,S187,S186,S117}'::text[]))
Total runtime: 5845.796 ms
(30 rows)

Ma configuration :
default_statistics_target = 1000
constraint_exclusion = partition
random_page_cost = 1.5

la machine a 32 Go de ram

je vois bien la difference d'utilisation de l'index, mais je ne vois pas pourquoi il estime un COST a presque 3 000 000 alors que le resultats est 10 fois plus rapide.

Merci d'avance pour votre aide.

Hors ligne

#2 29/12/2010 13:00:08

arthurr
Membre

Re : tables partitionnées - Perf avant ANALYSE

j'ai oublie la requete smile
explain (analyse true) select name, dav, id_source, id_fourniture, count(*), min(maj), max(maj) from documents join sources on (documents.id_source=sources.id) where sources.name in ('S060','S139','S141','S187','S186','S117') and dav>='2010-11-01' group by dav, id_fourniture, id_source, name order by name, dav;

Hors ligne

#3 29/12/2010 17:33:31

frost242
Administrateur

Re : tables partitionnées - Perf avant ANALYSE

Bonjour,

Vous nous présentez le résultat d'un EXPLAIN simple et d'un EXPLAIN ANALYZE. Le premier va simplement vous donner le plan d'exécution estimé, tandis que le second va vous donner le plan d'exécution estimé mais va y ajouter des statistiques d'exécution. Or, la collecte de ses statistiques à un coût qui fait grimper rapidement le temps d'exécution de la requête.
En fait, je ne comprends pas vraiment si vous fournissez les temps d'exécution des deux EXPLAIN ou bien les temps d'exécution réels de votre requête ?


Thomas Reiss

Hors ligne

#4 29/12/2010 18:19:43

arthurr
Membre

Re : tables partitionnées - Perf avant ANALYSE

oui, la premiere fois (avant la vacuum analyse) j'ai lance la requete qui s'est executee en 500ms, j'ai recupere le explain mais sans faire le analyse ...
la seconde fois (apres le vacuum analyse), j'ai lance la requete avec le explain analyse.

desole de ne pas avoir ete assez clair.

Merci

Hors ligne

#5 29/12/2010 19:12:04

frost242
Administrateur

Re : tables partitionnées - Perf avant ANALYSE

Et si vous lancez la requête sans le explain analyze ? (par curiosité). J'essayerai de voir demain si je peux vous aider, car je dois filer.


Thomas Reiss

Hors ligne

#6 30/12/2010 09:59:57

arthurr
Membre

Re : tables partitionnées - Perf avant ANALYSE

merci de votre interet !

en resume :
avant vacuum analyze  : 500 ms
apres vacuum analyze  : 5000 ms

Hors ligne

Pied de page des forums