Vous n'êtes pas identifié(e).

Pages : 1 2 3 4 5 6

#101 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 03/05/2010 09:30:48

gom

Je crois que ma requête peut encore être optimisée, mais je vais encore avoir besoin de vos conseils.

http://explain.depesz.com/s/BlJ

explain.depesz.com a écrit :

HashAggregate  (cost=3809696.22..3813839.33 rows=110483 width=82) (actual time=348760.149..349421.049 rows=363524 loops=1)
  ->  Hash Join  (cost=55653.34..3805000.69 rows=110483 width=82) (actual time=11838.695..347702.662 rows=363524 loops=1)
        Hash Cond: (gtin.cod_tmarq = type_marque.cod_tmarq)
        ->  Hash Join  (cost=55652.25..3803449.02 rows=118867 width=83) (actual time=11829.967..347307.814 rows=381684 loops=1)
              Hash Cond: ((gtin.aacc_number)::text = (ref_accords.aacc_numero)::text)
              ->  Hash Join  (cost=51190.15..3791486.94 rows=420754 width=82) (actual time=11470.691..345928.471 rows=1209316 loops=1)
                    Hash Cond: ((vte_hbd.gtin)::text = (gtin.gencode)::text)
                    ->  Hash Join  (cost=20.66..3727415.76 rows=632302 width=57) (actual time=18.839..327313.381 rows=4067925 loops=1)
                          Hash Cond: ((vte_hbd.anneesem)::text = (calendrier.anneesem)::text)
                          ->  Seq Scan on vte_hbd  (cost=0.00..3337134.24 rows=102383424 width=46) (actual time=7.542..287561.365 rows=102383428 loops=1)
                          ->  Hash  (cost=20.47..20.47 rows=15 width=27) (actual time=11.156..11.156 rows=5 loops=1)
                                ->  Index Scan using calendrier_anneesem_idx on calendrier  (cost=0.00..20.47 rows=15 width=27) (actual time=11.144..11.150 rows=5 loops=1)
                                      Index Cond: (((anneesem)::text >= '2010S09'::text) AND ((anneesem)::text <= '2010S13'::text))
                    ->  Hash  (cost=43809.61..43809.61 rows=588790 width=39) (actual time=11451.665..11451.665 rows=586767 loops=1)
                          ->  Seq Scan on gtin  (cost=0.00..43809.61 rows=588790 width=39) (actual time=7.632..11042.778 rows=586767 loops=1)
                                Filter: ((gtin)::text !~~ '%000000'::text)
              ->  Hash  (cost=4336.48..4336.48 rows=10050 width=44) (actual time=359.230..359.230 rows=10602 loops=1)
                    ->  Seq Scan on ref_accords  (cost=0.00..4336.48 rows=10050 width=44) (actual time=5.497..350.629 rows=10602 loops=1)
                          Filter: (((rgtp_code)::text = ANY (('{1,2,3,5}'::character varying[])::text[])) OR ('*'::text = ANY ('{1,2,3,5}'::text[])))
        ->  Hash  (cost=1.04..1.04 rows=4 width=7) (actual time=8.716..8.716 rows=4 loops=1)
              ->  Seq Scan on type_marque  (cost=0.00..1.04 rows=4 width=7) (actual time=8.708..8.711 rows=4 loops=1)
Total runtime: 349521.383 ms

Je ne vois pas pourquoi il fait un Seq Scan sur "vte_hbd" étant donné que j'ai cet Index là :

-- Index: mon_schema.vte_hbd_a_s_idx

-- DROP INDEX mon_schema.vte_hbd_a_s_idx;

CREATE INDEX vte_hbd_a_s_idx
  ON mon_schema.vte_hbd
  USING btree
  (anneesem)
TABLESPACE "TBS_DIM_INDEX_F";

#102 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 03/05/2010 09:13:53

gom

Yououuuuuuuuuuh ! Marc Cousin : roi de PostgreSQL ! cool

Merci beaucoup, ça fonctionne grâce à IMMUTABLE. wink


Gôm

#103 Re : Général » Formation PostgreSQL pour un Ingénieur Décisionnel ? » 01/05/2010 22:11:59

gom

Je prends ! big_smile

#104 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 01/05/2010 11:39:37

gom

Heu bah comment je peux faire autrement ?! Je suis bien obligé d'utiliser ma fonction !

#105 Re : Général » Formation PostgreSQL pour un Ingénieur Décisionnel ? » 01/05/2010 11:37:43

gom

Merci Gleu et Flo. smile

Quel(s) organisme(s) me conseilleriez-vous ? Dalibo aurait quelque chose pour moi ?! wink

Je suis prêt à aller à Paris pour la formation, car de toute façon j'y vais régulièrement pour le boulot.


Gôm

#106 Re : Général » Formation PostgreSQL pour un Ingénieur Décisionnel ? » 30/04/2010 18:07:15

gom

OK, mais est-ce que mon besoin "Décisionnel" fait que je devrais axer mes demandes de formation sur des points plus ou moins précis concernant l'administration ?

#107 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 30/04/2010 18:05:57

gom

Aïe, mais moi je sais bien que c'est mieux avec ! big_smile

Pas moyen de forcer l'utilisation de l'Index ?

#108 Général » Formation PostgreSQL pour un Ingénieur Décisionnel ? » 30/04/2010 17:20:27

gom
Réponses : 7

Bonjour,

Tout d'abord, je suis désolé si mon post n'est pas au bon endroit, mais je ne savais pas du tout où poster ! hmm


Mon entreprise me propose de faire une formation DBA PostgreSQL niveau 2 ... sauf que ce n'est qu'un libellé "en l'air". Je ne suis inscrit à aucune session de formation pour le moment (et l'organisme n'est pas choisi).

Je voudrais avoir votre avis pour cibler au mieux mon besoin de formation et si possible la société nantaise qui pourra me la dispenser.


Je suis donc dans le Décisionnel où je bosse exclusivement sur la suite BO (6.5, XI R2, XI 3.1), mais également prochainement avec Talend (TOS 4.0) sur un autre projet où BO est également utilisé mais que pour la partie Reporting. C'est une application maison en JAVA qui sert d'ETL.


Sachant que je n'utilise donc PostgreSQL qu'en tant qu'entrepôts de données, sur quels éléments de l'administration devrais-je insister pour être préparer au mieux à tuner un PostgreSQL pour une utilisation purement Décisionnel ?



Comme toujours ... merci d'avance. smile

Gôm

#109 PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 30/04/2010 16:53:34

gom
Réponses : 15

Bonjour,

Je viens de créer une fonction me permettant de retourner un numéro de semaine à partir d'un numéro de mois (voir jeu d'essai en commentaire dans la fonction). Je suis obligé de faire ainsi car notre table calendrier ne suit pas le calendrier officiel ... spécificité client ... bref ! tongue


-- Function: mon_schema.f_sem_deb_intervalle(character varying, integer, integer)

-- DROP FUNCTION mon_schema.f_sem_deb_intervalle(character varying, integer, integer);

CREATE OR REPLACE FUNCTION mon_schema.f_sem_deb_intervalle(annee_mois character varying, nb_annee_deduire integer, nb_mois_deduire integer)
  RETURNS character varying AS
$BODY$
declare

	v_annee integer;
	v_mois integer;
	v_annee_final integer;
	v_mois_final integer;
	v_annee_mois_final character varying(7);
	v_annee_sem_deb character varying(7);

begin

	-- Jeu d'essai : f_sem_deb_intervalle(2010M03, 1, 6)

	-- Année extraite à partir du paramètre correspondant à l'année et mois de référence "annee_mois"
	v_annee := substr(annee_mois, 1, 4); -- 2010

	-- Mois extrait à partir du paramètre correspondant à l'année et mois de référence "annee_mois"
	v_mois := substr(annee_mois, 6, 2); -- 3

	v_annee_final := v_annee - nb_annee_deduire; -- 2009

	-- "- 1", car on ne déduit pas le mois courant
	if nb_mois_deduire = 1 then
		v_mois_final := v_mois - 1;
	else
		if nb_mois_deduire > 1 then
			v_mois_final := v_mois - (nb_mois_deduire - 1); -- 3 - (6 - 1) = -2
		else
			v_mois_final := v_mois;
		end if;
	end if;

	if v_mois_final <= 0 then -- oui
		v_mois_final := 12 + v_mois_final; -- 12 + -2 = 10
		v_annee_final := v_annee_final - 1; -- 2008
	end if;

	v_annee_mois_final := trim(to_char(v_annee_final, '0000')) || 'M' || trim(to_char(v_mois_final, '00')); -- 2008M10

	v_annee_sem_deb := (SELECT anneesem FROM mon_schema.calendrier WHERE anneemois = v_annee_mois_final AND prem_sem_mois = 1); -- 2008S40

	return v_annee_sem_deb;
end;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;
ALTER FUNCTION mon_schema.f_sem_deb_intervalle(character varying, integer, integer) OWNER TO user_mon_schema;

Le problème est que désormais, mon index sur ma table "calendrier" n'est plus utilisé ?!


La requête où cette fonction est utilisée :

SELECT
  mon_schema.ref_accords.code_gt,
  mon_schema.calendrier.annee,
  mon_schema.calendrier.semaine,
  mon_schema.calendrier.mois_affectation,
  mon_schema.calendrier.num_mois_affectation,
  mon_schema.type_marque.libelle_court_tmarq,
  mon_schema.ref_accords.AADR_RAISSOC,
  mon_schema.gtin.gencode,
  sum(mon_schema.vte_hbd.ca_ht_avec_droit_taxes),
  sum(mon_schema.vte_hbd.marge_val_hbd),
  case when sum(mon_schema.vte_hbd.ca_ht_avec_droit_taxes) = 0
  then 0
  else sum(mon_schema.vte_hbd.marge_val_hbd)/sum(mon_schema.vte_hbd.ca_ht_avec_droit_taxes)
end
,
  sum(mon_schema.vte_hbd.3NET_COUT_HBD_HOP),
  sum(mon_schema.vte_hbd.3NET_COUT_HBD_OP),
  sum(mon_schema.vte_hbd.Marge_val_hbd_OP),
  sum(mon_schema.vte_hbd.Marge_val_hbd_HOP)
FROM
  mon_schema.ref_accords INNER JOIN mon_schema.gtin ON (mon_schema.gtin.aacc_number=mon_schema.ref_accords.aacc_numero)
   INNER JOIN mon_schema.vte_hbd ON (mon_schema.vte_hbd.gtin=mon_schema.gtin.gencode)
   INNER JOIN mon_schema.calendrier ON (mon_schema.vte_hbd.anneesem=mon_schema.calendrier.anneesem)
   INNER JOIN mon_schema.type_marque ON (mon_schema.type_marque.cod_tmarq= mon_schema.gtin.cod_tmarq)
  
WHERE
( mon_schema.gtin.gencode NOT LIKE '%000000'  )
  AND  
  (
   ( mon_schema.calendrier.anneesem between mon_schema.f_sem_deb_intervalle(( '2010M03' ), 0, 0) and mon_schema.f_sem_fin_intervalle(( '2010M03' ), 0, 0)  )
   AND
   ( mon_schema.ref_accords.code_gt in ('1', '2', '3', '5') or ('*' in ('1', '2', '3', '5')) )
  )
GROUP BY
  mon_schema.ref_accords.code_gt, 
  mon_schema.calendrier.annee, 
  mon_schema.calendrier.semaine, 
  mon_schema.calendrier.mois_affectation, 
  mon_schema.calendrier.num_mois_affectation, 
  mon_schema.type_marque.libelle_court_tmarq, 
  mon_schema.ref_accords.AADR_RAISSOC, 
  mon_schema.gtin.gencode

Le plan d'exécution :

Explain Plan a écrit :

GroupAggregate  (cost=4195170.72..4370739.46 rows=2128106 width=82)
  ->  Sort  (cost=4195170.72..4200490.98 rows=2128106 width=82)
        Sort Key: ref_accords.code_gt, calendrier.annee, calendrier.semaine, calendrier.mois_affectation, calendrier.num_mois_affectation, type_marque.libelle_court_tmarq, ref_accords.aadr_raissoc, gtin.gencode
        ->  Hash Join  (cost=64108.33..3971494.66 rows=2128106 width=82)
              Hash Cond: ((vte_hbd.gtin)::text = (gtin.gencode)::text)
              ->  Hash Join  (cost=1373.00..3832581.68 rows=10979318 width=57)
                    Hash Cond: ((vte_hbd.anneesem)::text = (calendrier.anneesem)::text)
                    ->  Seq Scan on vte_hbd  (cost=0.00..3337384.00 rows=102408400 width=46)
                    ->  Hash  (cost=1369.74..1369.74 rows=261 width=27)
                          ->  Seq Scan on calendrier  (cost=0.00..1369.74 rows=261 width=27)
                                Filter: (((anneesem)::text >= (mon_schema.f_sem_deb_intervalle('2010M03'::character varying, 0, 0))::text) AND ((anneesem)::text <= (mon_schema.f_sem_fin_intervalle('2010M03'::character varying, 0, 0))::text))
              ->  Hash  (cost=60825.83..60825.83 rows=152760 width=39)
                    ->  Hash Join  (cost=4462.64..60825.83 rows=152760 width=39)
                          Hash Cond: (gtin.cod_tmarq = type_marque.cod_tmarq)
                          ->  Hash Join  (cost=4461.55..58681.38 rows=164205 width=40)
                                Hash Cond: ((gtin.aacc_number)::text = (ref_accords.aacc_numero)::text)
                                ->  Seq Scan on gtin  (cost=0.00..43820.88 rows=583793 width=39)
                                      Filter: ((gencode)::text !~~ '%000000'::text)
                                ->  Hash  (cost=4336.48..4336.48 rows=10006 width=44)
                                      ->  Seq Scan on ref_accords  (cost=0.00..4336.48 rows=10006 width=44)
                                            Filter: (((code_gt)::text = ANY (('{1,2,3,5}'::character varying[])::text[])) OR ('*'::text = ANY ('{1,2,3,5}'::text[])))
                          ->  Hash  (cost=1.04..1.04 rows=4 width=7)
                                ->  Seq Scan on type_marque  (cost=0.00..1.04 rows=4 width=7)

Et, enfin, voici l'index qui est utilisé lorsque je n'utilise pas mes fonctions, mais que je passe en dur les numéros de semaine (mon_schema.calendrier.anneesem between '2010S09' and '2010S13') :

-- Index: mon_schema.calendrier_anneesem_idx

-- DROP INDEX mon_schema.calendrier_anneesem_idx;

CREATE INDEX calendrier_anneesem_idx
  ON mon_schema.calendrier
  USING btree
  (anneesem)
TABLESPACE "TBS_DIM_INDEX_F";

Gôm

PS : "Problème bonus" aucun index n'est utilisé du tout ... ? Je pense que c'est anormal concernant la table "vte_hbd", non ?

#110 Re : Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 19:01:23

gom

"Les combiner" ?! J'abuse un peu mais est-il possible d'avoir une petite explication ? smile

"C'est à tester" : est-ce que ça veut dire que 2 Index peut poser un quelconque problème ou que simplement un des 2 risque de ne servir à rien ?


Gôm

#111 Re : Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 18:38:19

gom

OK Marc, sauf que cet Index est utile pour d'autres requêtes où les valeurs null de "srp" ne sont PAS à exclure.

Je crée 2 Index, 1 avec le where et 1 sans  ?


Gôm

#112 Re : Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 17:13:08

gom

Le rapport BO s'affiche en 1 min 40 secondes au pire ... il mettait entre 10 et 15 minutes d'après les utilisateurs !

Donc pour répondre à gleu ... oui l'Index est mieux pour les perfs ! smile


Pour info, la requête seule depuis PgAdmin III dure 23 secondes ... BO a encore du boulot à faire pour la vitesse de rendu ! wink Enfin, y a tout de même 150 pages à sortir au format A3 !


Gôm

#113 Re : Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 16:25:02

gom
gleu a écrit :

Un EXPLAIN ANALYZE donne beaucoup plus d'informations et permettrait de répondre à vos questions. Là, on manque d'éléments.

Tout ce qu'on voit là, c'est qu'il estime que toute la charge de la requête se fera sur le Seq Scan de ventes. Donc quelques infos supplémentaires seraient intéressantes :

* EXPLAIN ANALYZE de la requête
* création d'un index sur anneesem de ventes, puis ANALYZE, puis EXPLAIN ANALYZE de la requête
* SELECT anneesem, count(*) FROM ventes GROUP BY anneesem

Donc ...


Création de l'Index et ANALYSE :

CREATE INDEX idx_ventes_as ON alim.ventes USING btree (anneesem) TABLESPACE "TBS_FACT_INDEX";

ANALYSE alim.ventes;

EXPLAIN ANALYSE (avec nouvel Index) :

HashAggregate  (cost=4111903.79..4116085.58 rows=334543 width=132) (actual time=22123.576..22705.905 rows=436143 loops=1)
  ->  Hash Join  (cost=97220.23..4101031.15 rows=334543 width=132) (actual time=6751.880..20976.364 rows=436143 loops=1)
        Hash Cond: ((ref_gtin.aacc_number)::text = (ref_accord.num_accord)::text)
        ->  Hash Join  (cost=92796.39..4088661.91 rows=334543 width=109) (actual time=6387.703..20033.292 rows=471410 loops=1)
              Hash Cond: ((ventes.code_sca)::text = (ref_centrale.nom_centrale)::text)
              ->  Nested Loop  (cost=92794.52..4084060.07 rows=334543 width=100) (actual time=6387.106..19556.842 rows=471410 loops=1)
                    ->  Index Scan using calendrier_anneesem_idx on calendrier  (cost=0.00..4.27 rows=1 width=16) (actual time=12.553..12.557 rows=1 loops=1)
                          Index Cond: ((cal_anneesem)::text = '2010S10'::text)
                    ->  Hash Join  (cost=92794.52..4080710.37 rows=334543 width=100) (actual time=6374.536..19225.554 rows=471410 loops=1)
                          Hash Cond: ((ventes.gtin)::text = (ref_gtin.code_gtin)::text)
                          ->  Bitmap Heap Scan on ventes  (cost=44011.42..4024400.05 rows=334543 width=44) (actual time=551.201..12674.660 rows=476267 loops=1)
                                Recheck Cond: ((cal_anneesem)::text = '2010S10'::text)
                                Filter: (srp IS NOT NULL)
                                ->  Bitmap Index Scan on idx_ventes_as  (cost=0.00..43927.78 rows=3387203 width=0) (actual time=526.177..526.177 rows=2814044 loops=1)
                                      Index Cond: ((cal_anneesem)::text = '2010S10'::text)
                          ->  Hash  (cost=41930.82..41930.82 rows=548182 width=70) (actual time=5823.159..5823.159 rows=548954 loops=1)
                                ->  Seq Scan on ref_gtin  (cost=0.00..41930.82 rows=548182 width=70) (actual time=3.932..5397.315 rows=548954 loops=1)
              ->  Hash  (cost=1.39..1.39 rows=39 width=14) (actual time=0.566..0.566 rows=39 loops=1)
                    ->  Seq Scan on ref_centrale  (cost=0.00..1.39 rows=39 width=14) (actual time=0.524..0.540 rows=39 loops=1)
        ->  Hash  (cost=3980.04..3980.04 rows=35504 width=44) (actual time=364.155..364.155 rows=35504 loops=1)
              ->  Seq Scan on ref_accord  (cost=0.00..3980.04 rows=35504 width=44) (actual time=6.399..338.508 rows=35504 loops=1)
Total runtime: 22832.695 ms

Gôm

#114 Re : Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 13:28:03

gom

OK, je vais relancer la création de l'index sur le temps du midi ... je verrai bien.

Petite extra question, j'ai 3 Index qui existent déjà sur cette table là :

CREATE INDEX idx_ventes_pk
  ON alim.ventes
  USING btree
  (sem, annee, gtin, code_sca)
TABLESPACE "TBS_FACT_INDEX";
CREATE INDEX idx_ventes_gtin
  ON alim.ventes
  USING btree
  (gtin)
TABLESPACE "TBS_FACT_INDEX";
CREATE INDEX idx_ventes_s_a
  ON alim.ventes
  USING btree
  (sem, annee)
TABLESPACE "TBS_FACT_INDEX";

Ne faut-il pas créer le même que le 1er Index avec "anneesem" à la place de "sem, annee" ? Au lieu de créer un Index que pour "anneesem" ? neutral


Gôm

#115 Re : Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 12:59:44

gom
gleu a écrit :

* EXPLAIN ANALYZE de la requête
* création d'un index sur anneesem de ventes, puis ANALYZE, puis EXPLAIN ANALYZE de la requête
* SELECT anneesem, count(*) FROM ventes GROUP BY anneesem

1/

Veut pas s'afficher malgré une attente de 10 minutes, ça demande combien de temps environ ?


2/

CREATE INDEX idx_ventes_anneesem ON alim.ventes USING btree (anneesem) TABLESPACE "TBS_FACT_INDEX"

J'ai lancé la création à 10h00 et elle n'était toujours pas finie. J'ai des traitements à 12h00, donc j'ai fait un pg_cancel_backend. hmm



3/

Toujours pas de résultat depuis plusieurs minutes ... normal puisque l'Index n'a pu être créé, non ?



Gôm

#116 Re : Optimisation » [8.3] Utilisation de la RAM ? » 19/03/2010 10:49:05

gom

Merci beaucoup gleu, votre article est très intéressant !

Sachant que je travaille sur un entrepôt de données et non sur une base de données "classique" ne faut-il pas pondérer certains des points de l'article ?

Vous dites en conclusion qu'il faut tester des valeurs plus importantes pour "maintenance_work_mem" si les opérations de VACUUM et de créations d'Index sont particulièrement longues ... ce qui est mon cas. Ce paramètre est positionné à 512 Mo, est-ce suffisant dans le cas d'une base décisionnelle et eu égard aux caractéristiques de mon serveur de PROD (voir lien du 1er post) ?


Gôm

#117 Optimisation » Comment identifier précisément l'Index qu'il faut créer ? » 19/03/2010 10:23:12

gom
Réponses : 15

Bonjour à tous,

J'ai des requêtes qui prennent beaucoup de temps à s'exécuter et je pense qu'il me manque des Index.

SELECT
  alim.ref_accord.code_gt,
  alim.ref_gtin.code_gtin,
  alim.ref_accord.num_accord,
  alim.ref_accord.adresse_raissoc,
  alim.ref_gtin.lib_prd,
  alim.ref_centrale.nom_centrale,
  alim.ventes.srp,
  sum(alim.ventes.dor_qte),
  alim.calendrier.annee,
  alim.calendrier.semaine,
  alim.ventes.ide_source,
  alim.ventes.srp_modal,
  alim.ventes.srp_theo
FROM
  alim.ref_gtin,
  alim.ref_accord,
  alim.ref_centrale,
  alim.ventes,
  alim.calendrier
WHERE
  ( alim.ref_gtin.aacc_number=alim.ref_accord.num_accord  )
  AND  ( alim.ref_centrale.nom_centrale=alim.ventes.code_sca  )
  AND  ( alim.ref_gtin.code_gtin=alim.ventes.gtin  )
  AND  ( alim.calendrier.cal_anneesem=alim.ventes.anneesem  )
  AND  
  (
   ( alim.ref_accord.code_gt in ('1', '2', 'A') )
   AND
   ( alim.calendrier.cal_anneesem = '2009S36' )
   AND alim.ventes.srp is not null  
  )
GROUP BY
  alim.ref_accord.code_gt, 
  alim.ref_gtin.code_gtin, 
  alim.ref_accord.num_accord, 
  alim.ref_accord.adresse_raissoc, 
  alim.ref_gtin.lib_prd, 
  alim.ref_centrale.nom_centrale, 
  alim.ventes.srp, 
  alim.calendrier.annee, 
  alim.calendrier.semaine, 
  alim.ventes.ide_source, 
  alim.ventes.srp_modal, 
  alim.ventes.srp_theo
Explain Plan a écrit :

HashAggregate  (cost=12079946.56..12083307.93 rows=268910 width=132)
  ->  Hash Join  (cost=53208.81..12071206.98 rows=268910 width=132)
        Hash Cond: ((ref_gtin.aacc_number)::text = (ref_accord.num_accord)::text)
        ->  Hash Join  (cost=48784.97..12060396.53 rows=268910 width=109)
              Hash Cond: ((ventes.code_sca)::text = (ref_centrale.nom_centrale)::text)
              ->  Nested Loop  (cost=48783.10..12056697.14 rows=268910 width=100)
                    ->  Index Scan using calendrier_anneesem_idx on calendrier  (cost=0.00..4.27 rows=1 width=16)
                          Index Cond: ((anneesem)::text = '2010S10'::text)
                    ->  Hash Join  (cost=48783.10..12054003.77 rows=268910 width=100)
                          Hash Cond: ((ventes.gtin)::text = (ref_gtin.code_gtin)::text)
                          ->  Seq Scan on ventes  (cost=0.00..11999170.20 rows=268910 width=44)
                                Filter: ((srp IS NOT NULL) AND ((cal_anneesem)::text = '2009S36'::text))
                          ->  Hash  (cost=41930.82..41930.82 rows=548182 width=70)
                                ->  Seq Scan on ref_gtin  (cost=0.00..41930.82 rows=548182 width=70)
              ->  Hash  (cost=1.39..1.39 rows=39 width=14)
                    ->  Seq Scan on ref_centrale  (cost=0.00..1.39 rows=39 width=14)
        ->  Hash  (cost=3980.04..3980.04 rows=35504 width=44)
              ->  Seq Scan on ref_accord  (cost=0.00..3980.04 rows=35504 width=44)

Faut-il que je crée 3 Index sur la table "ventes", un sur chacun des champs suivants, ou un seul Index regroupant ces 3 champs … ou 4 Index ?

- code_sca
- gtin
- anneesem


Le fait que je n'ai aucune condition (rien dans le WHERE) portant sur l'un de ces champs de ma table "ventes" entre-t-il en compte ? Si c'était le cas est-ce que la réponse à ma question ci-dessus aurait changée ?


Si je vous pose toutes ces questions, c'est parce que ma table "ventes" a beaucoup de lignes (count(*) = 319 millions environ) et je ne veux pas perdre du temps à créer des Index pour rien. Surtout qu'il faut surement que je fasse de la maintenance sur cette table après (ANALYSE ou je ne sais quoi), non ?


Gôm

#118 Optimisation » [8.3] Utilisation de la RAM ? » 11/03/2010 13:03:43

gom
Réponses : 3

Bonjour,

Je suis en train d'utiliser énormément mon entrepôt de données PostgreSQL 8.3 de PROD, via Business Objects (actualisation de rapports en masse), et la mémoire vive utilisée n'est que d'1 Go (oscille entre 1,30 et 1,40) alors que mon serveur dispose de 8 Go !

Un nouveau problème dans mon paramétrage ?

Voir ici un extrait du paramétrage : http://forums.postgresql.fr/viewtopic.p … 4160#p4160


Gôm

#119 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 14:55:26

gom

OK, "max_fsm_relations" à 5000.


Merci ÉNORMÉMENT pour votre aide ! cool

Gôm

#120 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 14:48:13

gom

J'ai 1260 objets en PROD et 863 en DEV ...

Je positionne "max_fsm_relations" à 2000 sur les 2 serveurs ou dois-je prendre davantage de marge de sécurité ?

#121 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 12:29:02

gom

Existe-t-il une requête permettant de connaître précisément le nombre d'objets ?

Ainsi je pourrai mettre une valeur la plus proche possible de la réalité, non ? Par exemple, si j'ai 12432 objets, alors je positionne "max_fsm_relations" à 10000 ?

#122 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 11:04:57

gom

OK, merci pour ces explications très détaillées. smile

Donc en résumé, je pense mettre :

DEV :

default_statistics_target : 100 (idem PROD)
shared_buffers : 4096 (idem PROD)
maintenance_work_mem : 262144 (soit 256 Mo)

PROD :

max_fsm_pages : 2048000 (idem DEV)

En PROD, dois-je également passer max_fsm_relations à 20000, comme c'est le cas sur DEV ?


Gôm

#123 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 10:38:24

gom

Ah mais au contraire, je suis très content que vous débattiez sur mon thread ! smile

Mais je veux bien encore un peu d'aide pour en finir avec le paramétrage de mes machines ! wink

gom a écrit :

Quels sont les critères qui me permettront de déterminer la bonne valeur de ces 2 paramètres ?

Gôm

#124 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 09:14:30

gom

Quels sont les critères qui me permettront de déterminer la bonne valeur de ces 2 paramètres ?

Très intéressant cet outil ! Je le teste aujourd'hui ou demain au pire. smile

#125 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 08:28:08

gom

OK, va pour 32 Mo.


Merci pour les explications.

Gôm

PS : Y avait aucune autre valeur suspecte dans les paramètres ?

Pages : 1 2 3 4 5 6

Pied de page des forums

Propulsé par FluxBB