Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#201 Re : Optimisation » tables partitionnées - Perf avant ANALYSE » 29/12/2010 18:19:43
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
#202 Re : Optimisation » tables partitionnées - Perf avant ANALYSE » 29/12/2010 13:00:08
j'ai oublie la requete 
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;
#203 Optimisation » tables partitionnées - Perf avant ANALYSE » 29/12/2010 12:54:46
- arthurr
- Réponses : 5
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.
#204 Re : Général » Soustraire 2 dates » 19/11/2010 15:17:58
Bonjour,
extract fonctionne avec un timestamp, et vous lui passez en parametre un interval (a vu d'oeil).
L'exemple suivant focntionne :
Select (extract(epoch from '2010-01-12'::timestamp) - extract(epoch from '2010-01-11'::timestamp));
mais cela renvoi un nombre de secondes entre 2 dates
#205 Re : Général » [SQL] Ordre de tri non naturel » 22/10/2010 16:00:42
Il faut rajouter un DESC :
select * from n_code_pays order by pays='FRANCE' desc , pays;
#206 Re : Général » Supprimer un fichier dans une procédure stockée » 28/09/2010 10:54:48
vous pouvez :
1/ creer une table avec la liste des fichiers a supprimer
2/ lancer de facon reguliere un script (perl, ...) qui va supprimer les fichiers et les lignes de la table
#207 Re : Général » Equivalent de pgAdmin Server Status en ligne de commande » 28/09/2010 10:40:19
si vous voulez voir les cnx en cours : select * from pg_stat_activity
#208 Re : Général » modifier le codage d'une base de données » 22/09/2010 14:21:40
tu peux faire une sauvegarde de ta base qui est en LATIN1 vers UTF8 comme ca :
pg_dump -Fc -f tabase.dump --encoding='UTF8' TABASE
Apres tu dois pouvoir restorer en UTF8 sans probleme.
#209 Re : Général » Afficher le temps d'exécution d'une requête » 25/08/2010 11:30:22
bonjour,
dans psql : \timing permet de donner le temps d'execution de chaque requete
\timing [on|off] toggle timing of commands (currently on)#210 Re : Général » Conception » 08/02/2010 15:54:49
Merci pour vos reponses !
je crois que je vais creer 3 tables (alertes_maison, ....).
#211 Re : Général » Conception » 05/02/2010 12:14:11
Un truc du style :
table "objet" avec un id_objet et 3 tables heritees de cette meme table : maison, voiture, proprietaire
avec ca, je peux juste creer une table alerte et lier alerte avec ma table objet.
mais ca va complexifier les choses : liaisons entre proprietaire / maison / voiture.
je ne suis pas certain d'etre tres clair dans mes explications ...
#212 Général » Conception » 05/02/2010 11:05:55
- arthurr
- Réponses : 5
Bonjour,
Heureux de travailler avec Pg, j'ai une petite question de "savoir faire" concernant vos methodes de modelisations.
Dans le cadre d'un nouveau projet, je dois lier un certain nombre de tables a une seul.
Exemple bidon :
une table voiture
une table maison (0 a n voitures garees dans une maison))
une table proprietaire (qui possede 0 a n voitures et 0 a n maisons)
et pour chacune de ces tables (tres differentes), je dois gerer une nouvelle info. par exemple un historique d'alertes.
j'ai donc une table alerte (avec un id_alerte, une date, un type d'alerte).
je ne vois pas trop comment faire la liaison avec mes alertes et mes autres tables qui ont des PK differentes ...
Les solutions qui me viennent :
- j'ai pense au debut travailler avec des tables heritees (sur maison/voiture/propritaire) , mais j'ai besoin d'identifier facilement le propretaire et de connaitre ses biens (dans notre exemple).
- creer 3 tables : alerte_maison, alerte_voiture, alerte_proprietaire
- creer une table alerte (avec id_alerte, date, type_alerte) puis creer trois tables heritees de celle-ci : alerte_maison (avec la fk id_maison), alerte_voiture, ....
vous avez une solution "magique" ???
merci de votre aide