Messages de gom

gom · Optimisation

Quels pourrait être les risques de passer le random_page_cost de 2 à 4 pour mes autres requêtes ?

Gôm

gom · Optimisation

Je viens de le faire et la requête est passée en 48 secondes !!!

Plan d'exécution :

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

HashAggregate (cost=2195131.19..2198028.46 rows=193151 width=122) (actual time=48528.780..48529.558 rows=123 loops=1)
-> Hash Join (cost=352971.88..2190785.29 rows=193151 width=122) (actual time=5137.624..48351.471 rows=115085 loops=1)
Hash Cond: ((dwh_vte_hbd.dwh_anneesem)::text = (dwh_calendrier.dwh_anneesem)::text)
-> Hash Join (cost=352893.52..2187782.44 rows=198599 width=119) (actual time=5118.187..48242.015 rows=115085 loops=1)
Hash Cond: ((dwh_vte_hbd.dwh_gtin)::text = (dwh_gtin.gtin)::text)
-> Nested Loop (cost=303286.20..2082975.07 rows=14190414 width=94) (actual time=3485.537..39236.326 rows=3758060 loops=1)
-> Result (cost=0.00..0.51 rows=1 width=0) (actual time=13.882..13.884 rows=1 loops=1)
-> Bitmap Heap Scan on dwh_vte_hbd (cost=303286.20..1870118.34 rows=14190414 width=30) (actual time=3471.640..33985.951 rows=3758060 loops=1)
Recheck Cond: (((dwh_vte_hbd.dwh_anneesem)::text >= ((alim_dwh.f_mois_glissant_moins_n_deb('2010S13'::character varying, 1)))::text) AND ((dwh_vte_hbd.dwh_anneesem)::text <= ((alim_dwh.f_mois_glissant_moins_n_fin('2010S13'::character varying, 1)))::text))
-> Bitmap Index Scan on dwh_vte_hbd_a_s_idx (cost=0.00..299738.59 rows=14190414 width=0) (actual time=3409.026..3409.026 rows=3758060 loops=1)
Index Cond: (((dwh_vte_hbd.dwh_anneesem)::text >= ((alim_dwh.f_mois_glissant_moins_n_deb('2010S13'::character varying, 1)))::text) AND ((dwh_vte_hbd.dwh_anneesem)::text <= ((alim_dwh.f_mois_glissant_moins_n_fin('2010S13'::character varying, 1)))::text))
-> Hash (cost=49455.09..49455.09 rows=12179 width=53) (actual time=1632.401..1632.401 rows=44047 loops=1)
-> Merge Join (cost=46146.67..49455.09 rows=12179 width=53) (actual time=1420.420..1611.648 rows=44047 loops=1)
Merge Cond: (((dwh_gtin.sous_secteur)::text = (dwh_codelec.sous_secteur)::text) AND ((dwh_gtin.activite)::text = (dwh_codelec.activite)::text) AND ((dwh_gtin.groupe)::text = (dwh_codelec.groupe)::text) AND ((dwh_gtin.secteur)::text = (dwh_codelec.secteur)::text))
-> Sort (cost=41676.08..42221.70 rows=218250 width=28) (actual time=887.971..897.210 rows=45509 loops=1)
Sort Key: dwh_gtin.sous_secteur, dwh_gtin.activite, dwh_gtin.groupe, dwh_gtin.secteur
Sort Method: quicksort Memory: 5447kB
-> Hash Join (cost=1452.68..22322.08 rows=218250 width=28) (actual time=131.435..580.238 rows=45509 loops=1)
Hash Cond: ((dwh_gtin.aacc_number)::text = (dwh_acc_isis.aacc_numero)::text)
-> Seq Scan on dwh_gtin (cost=0.00..15670.43 rows=804393 width=47) (actual time=0.007..213.441 rows=804393 loops=1)
-> Hash (cost=1434.90..1434.90 rows=1422 width=24) (actual time=131.378..131.378 rows=1406 loops=1)
-> Seq Scan on dwh_acc_isis (cost=0.00..1434.90 rows=1422 width=24) (actual time=9.394..130.611 rows=1406 loops=1)
Filter: ((rgtp_code)::text = '3'::text)
-> Sort (cost=4470.52..4583.41 rows=45154 width=50) (actual time=531.890..543.423 rows=79387 loops=1)
Sort Key: dwh_codelec.sous_secteur, dwh_codelec.activite, dwh_codelec.groupe, dwh_codelec.secteur
Sort Method: quicksort Memory: 7148kB
-> Seq Scan on dwh_codelec (cost=0.00..979.54 rows=45154 width=50) (actual time=0.379..59.800 rows=45154 loops=1)
-> Hash (cost=48.99..48.99 rows=2349 width=19) (actual time=19.407..19.407 rows=2349 loops=1)
-> Seq Scan on dwh_calendrier (cost=0.00..48.99 rows=2349 width=19) (actual time=4.588..18.417 rows=2349 loops=1)
Total runtime: 48553.438 ms

A croire que ce n'est plus la même requête alors que si !!!

Gôm

gom · Optimisation

Il est actuellement à 2, alors que la valeur par défaut est 4.0 (je crois).

Que dois-je faire ?

Gôm

gom · Optimisation

Le work_mem est déjà à 300 MB.

Gôm

gom · Optimisation

Voici les statistiques de cet Index selon PgAdmin :

Parcours d'index : 2007658
Lignes d'index lues : 125076152
Lignes d'index récupérées : 125023331
Lecture des blocs d'index : 2588147
Accès aux blocs d'index : 16206391
Taille Index : 3842 MB

-- Index: alim_dwh."IDX_GTIN"

-- DROP INDEX alim_dwh."IDX_GTIN";

CREATE INDEX "IDX_GTIN"
  ON alim_dwh.dwh_vte_hbd
  USING btree
  (dwh_gtin);

N'ai-je pas un moyen d'optimiser cet Index et donc ma requête ? Pour info, elle met 35 minutes à s'exécuter et j'ai un timeout à 30 minutes dans mon application ce qui fait que mes utilisateurs n'ont plus leurs données !

Avant ça devait passer juste juste et maintenant, suite à un accroissement conséquent de la volumétrie, ça ne passe plus !

Gôm

PS : La table sur laquelle pointe cet Index contient 127.713.732 lignes pour 116 colonnes (soit 22 GB).

gom · Optimisation

Oui c'est bizarre, non ?

Je croyais que PostgreSQL était capable de mettre en cache et donc de ne pas avoir à reparcourir l'Index autant de fois ?

Gôm

gom · Optimisation

Bonjour à tous,

Pourriez-vous m'expliquer pourquoi ma requête est si longue, alors que des Index sont utilisés ?

Ma requête :

  SELECT
  alim_dwh.dwh_acc_isis.RGTP_CODE,
  alim_dwh.dwh_codelec.LIBELLE_ACTIVITE,
  alim_dwh.dwh_codelec.LIBELLE_GROUPE,
  alim_dwh.dwh_calendrier.dwh_mois_affectation,
  alim_dwh.dwh_calendrier.DWH_annee,
  dwh_mois_glissant_1.sem_deb,
  dwh_mois_glissant_1.sem_fin,
  sum(alim_dwh.dwh_vte_hbd.DWH_Marge_val_hbd),
  sum(alim_dwh.dwh_vte_hbd.dwh_ca_ht_avec_droit_taxes)
FROM
  alim_dwh.dwh_acc_isis INNER JOIN alim_dwh.dwh_gtin ON (alim_dwh.dwh_gtin.aacc_number=alim_dwh.dwh_acc_isis.aacc_numero)
   INNER JOIN alim_dwh.dwh_vte_hbd ON (alim_dwh.dwh_vte_hbd.dwh_gtin=alim_dwh.dwh_gtin.gtin)
   INNER JOIN alim_dwh.dwh_calendrier ON (alim_dwh.dwh_vte_hbd.dwh_anneesem=alim_dwh.dwh_calendrier.dwh_anneesem)
   INNER JOIN ( 
  select alim_dwh.f_mois_glissant_moins_n_deb('2010S13' , 1) as sem_deb, alim_dwh.f_mois_glissant_moins_n_fin('2010S13', 1) as sem_fin
  )  dwh_mois_glissant_1 ON (alim_dwh.dwh_vte_hbd.dwh_anneesem >= dwh_mois_glissant_1.sem_deb and alim_dwh.dwh_vte_hbd.dwh_anneesem <= dwh_mois_glissant_1.sem_fin)
   INNER JOIN alim_dwh.dwh_codelec ON (alim_dwh.dwh_codelec.activite=alim_dwh.dwh_gtin.activite and alim_dwh.dwh_codelec.groupe=alim_dwh.dwh_gtin.groupe and alim_dwh.dwh_codelec.secteur=alim_dwh.dwh_gtin.secteur and 
   alim_dwh.dwh_codelec.sous_secteur=alim_dwh.dwh_gtin.sous_secteur)
WHERE
  alim_dwh.dwh_acc_isis.RGTP_CODE in ('3')
GROUP BY
  alim_dwh.dwh_acc_isis.RGTP_CODE, 
  alim_dwh.dwh_codelec.LIBELLE_ACTIVITE, 
  alim_dwh.dwh_codelec.LIBELLE_GROUPE, 
  alim_dwh.dwh_calendrier.dwh_mois_affectation, 
  alim_dwh.dwh_calendrier.DWH_annee, 
  dwh_mois_glissant_1.sem_deb, 
  dwh_mois_glissant_1.sem_fin

Le plan d'exécution :

"HashAggregate (cost=865580.19..868477.45 rows=193151 width=122) (actual time=2107489.872..2107490.682 rows=123 loops=1)"
" -> Hash Join (cost=643.09..861234.29 rows=193151 width=122) (actual time=313.614..2107215.109 rows=115085 loops=1)"
" Hash Cond: ((dwh_vte_hbd.dwh_anneesem)::text = (dwh_calendrier.dwh_anneesem)::text)"
" -> Nested Loop (cost=564.74..858231.43 rows=198599 width=119) (actual time=311.272..2107054.459 rows=115085 loops=1)"
" Join Filter: (((dwh_vte_hbd.dwh_anneesem)::text >= ((alim_dwh.f_mois_glissant_moins_n_deb('2010S13'::character varying, 1)))::text) AND ((dwh_vte_hbd.dwh_anneesem)::text <= ((alim_dwh.f_mois_glissant_moins_n_fin('2010S13'::character varying, 1)))::text))"
" -> Result (cost=0.00..0.51 rows=1 width=0) (actual time=2.266..2.267 rows=1 loops=1)"
" -> Nested Loop (cost=564.74..831420.08 rows=1787389 width=55) (actual time=173.747..2103929.348 rows=4378669 loops=1)"
" -> Hash Join (cost=564.74..49998.47 rows=12179 width=53) (actual time=4.946..3314.409 rows=44047 loops=1)"
" Hash Cond: ((dwh_gtin.aacc_number)::text = (dwh_acc_isis.aacc_numero)::text)"
" -> Nested Loop (cost=0.00..49143.61 rows=44888 width=72) (actual time=0.157..3065.498 rows=786443 loops=1)"
" -> Seq Scan on dwh_codelec (cost=0.00..979.54 rows=45154 width=50) (actual time=0.006..76.303 rows=45154 loops=1)"
" -> Index Scan using idx_dwh_gtin_codelec on dwh_gtin (cost=0.00..1.05 rows=1 width=47) (actual time=0.021..0.059 rows=17 loops=45154)"
" Index Cond: (((dwh_gtin.activite)::text = (dwh_codelec.activite)::text) AND ((dwh_gtin.groupe)::text = (dwh_codelec.groupe)::text) AND ((dwh_gtin.secteur)::text = (dwh_codelec.secteur)::text) AND ((dwh_gtin.sous_secteur)::text = (dwh_codelec.sous_secteur)::text))"
" -> Hash (cost=546.97..546.97 rows=1422 width=24) (actual time=1.799..1.799 rows=1406 loops=1)"
" -> Index Scan using dwh_acc_isis_rgtp_code on dwh_acc_isis (cost=0.00..546.97 rows=1422 width=24) (actual time=0.024..1.286 rows=1406 loops=1)"
" Index Cond: ((rgtp_code)::text = '3'::text)"
" -> Index Scan using "IDX_GTIN" on dwh_vte_hbd (cost=0.00..62.32 rows=147 width=30) (actual time=3.422..47.492 rows=99 loops=44047)"
" Index Cond: ((dwh_vte_hbd.dwh_gtin)::text = (dwh_gtin.gtin)::text)"
" -> Hash (cost=48.99..48.99 rows=2349 width=19) (actual time=2.316..2.316 rows=2349 loops=1)"
" -> Seq Scan on dwh_calendrier (cost=0.00..48.99 rows=2349 width=19) (actual time=0.016..1.412 rows=2349 loops=1)"
"Total runtime: 2107493.094 ms"

Total runtime = 35 minutes !

Vous m'aviez conseillé une fois précédente de m'aider de ce site : http://explain.depesz.com/s/lYY mais je n'arrive pas à savoir quoi faire à partir des indications fournies.

Gôm

gom · Optimisation

OK, merci ... encore !

Gôm

gom · Optimisation

Tant que tu es là ...

pg_ctl reload -D '/app/dwh/pgsql/data' -s -m fast

C'est la bonne manière de faire ?

Gôm

gom · Optimisation

OK, c'est fait.

Merci merci beaucoup ! Vous êtes vraiment tous très forts !!!

Gôm

gom · Optimisation

OK, merci, par contre quelles sont les conséquences de laisser ça ?

# - Optimiseur -
effective_cache_size = 5376MB
random_page_cost = 2.0

Gôm

gom · Optimisation

Nouvelle découverte !

A partir de cette requête SQL je suis capable de lister toutes les tables de mon entrepôt de données qui possèdent au moins un index et donc pour lesquelles je dois supprimer et recréer le ou les index !

SELECT * 
FROM pg_tables 
WHERE schemaname not in ('information_schema', 'pg_catalog', 'public') 
and hasindexes;

Gôm

gom · Optimisation

Je viens de trouver ce script, mais je ne le comprends pas donc si vous pouviez me donner quelques explications ce serait merveilleux !

DECLARE @indexName sysname --Changed to sysname, since that's what it was
DECLARE @tableName sysname
DECLARE @dropIndexSql NVARCHAR(4000)

DECLARE tableIndexes CURSOR FOR
SELECT name,OBJECT_NAME(ID) FROM sysindexes
WHERE OBJECTPROPERTY(ID,N'IsTable') = 1 
AND OBJECTPROPERTY(ID,N'IsMSShipped') = 0
AND indid 0 --Is this right? Wouldn't this attempt to drop clustered PK?
AND indid < 255
AND INDEXPROPERTY(id, name, 'IsStatistics') = 0
OPEN tableIndexes
FETCH NEXT FROM tableIndexes INTO @indexName, @tableName
WHILE @@fetch_status = 0
BEGIN
SET @dropIndexSql = N' DROP INDEX ' + @tableName + '.'  + @indexName
EXEC sp_executesql @dropIndexSql
FETCH NEXT FROM tableIndexes INTO @indexName, @tableName
END
CLOSE tableIndexes
DEALLOCATE tableIndexes

Source : http://bytes.com/topic/sql-server/answe … s-database

Gôm

gom · Optimisation

Marc Cousin a écrit :

Désolé. Par défaut, les systèmes de fichier ext (2,3,4) sous Linux ont 5% de blocs réservés à root. 5% de 300Go, c'est 15Go. Donc si tu as un FS de 300Go, il y en a en fait 285 d'utilisables par les utilisateurs. Ce qui expliquerait ton problème je pense.

OK merci pour l'explication. Pour info ... http://eric.quinton.free.fr/spip.php?article36

daamien a écrit :

Effectivement la solution à court terme consiste à détruire/recréer les index...
Par contre, si vous n'avez plus de place dans la baie SAN alors votre soucis dépasse largement le problème du REINDEX.... Notamment si la partition qui héberge les WALs est saturée vous allez au devant d'un sérieux plantage.
Un disque de 500Go coute 50€, je comprends pas ce qui vous empêche d'augmenter votre volume de stockage..

Les "WALs" ? Une petite explication sur les risques ?

Sinon, est-ce qu'il existe une commande (sql ? pgsql ? curseur ?) qui permet de supprimer et recréer mes index dynamiquement ? Mon objectif est que si quelqu'un ajoute, modifie ou supprime un index sans que je sois au courant, alors mon script de maintenance prendra automatiquement en compte ces changements.

Du genre :

1/ Lecture d'une table système qui contient toutes les informations nécessaires sur l'ensemble des index actuellement présents dans mon entrepôt de données afin de créer un script "recréation de tous mes index" ;
2/ Suppression de tous mes index en générant des DROP INDEX via la table système énoncée ci-dessus ;
3/ VACUUM FULL ANALYSE;
4/ Création de mes index tout juste supprimés grâce à mon script "recréation de tous mes index" créé en 1/.

Le rêve quoi ...

Gôm

gom · Optimisation

Bonjour,

Bon j'ai un problème ... j'ai récupéré la configuration de notre serveur de production, qui possède les mêmes caractéristiques machine.

CPU : Bi Xeon (2 x 4 cœurs) 2,0 GHz
Mémoire vive : 8Go

Par contre, mon serveur de développement où j'ai mes 2 instances n'est pas un serveur dédié ! Il y a dessus des bases Oracle, des applications Java, etc.

Ma question est donc comment puis-je adapter ma configuration ci-dessous sans "trop" perturber les autres utilisateurs de ce serveur de développement ?!

# - Connexions -
listen_addresses = '*'

# - Memoire -
shared_buffers = 2GB
wal_buffers = 8MB
work_mem = 300MB
maintenance_work_mem = 512MB

# - Journaux de transactions -
checkpoint_segments = 50
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9

# - Optimiseur -
effective_cache_size = 5376MB
random_page_cost = 2.0

# - Statistiques -
track_activity_query_size = 4096

# - Traces -
log_filename = 'postgresql-%Y-%m-%d.log'
log_truncate_on_rotation = off
log_line_prefix = '%t [%p]: [%l-1] '
lc_messages = 'C'
log_connections = on
log_checkpoints = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0

# - Module pg_stat_statements -
shared_preload_libraries = 'pg_stat_statements'
custom_variable_classes = 'pg_stat_statements'
pg_stat_statements.max = 1000
pg_stat_statements.track = top
pg_stat_statements.save = on

Gôm

gom · Optimisation

Bonjour,

OS : Redhat 4.1.2 (64 bits)
1ère instance : PostgreSQL 8.2.13 (une dizaine de bases de données hétéroclites : dev, recette, validation, etc.)
2e instance : PostgreSQL 8.4.5 (un entrepôt de données de recette pour Business Objects où nous réalisons des alimentations hebdo et de la consultation ponctuellement (1 à 3 fois par mois))

Quelles questions dois-je me poser pour réaliser le paramétrage de mes 2 postgresql.conf ?

Merci d'avance.

Gôm

gom · Optimisation

Tu peux être plus explicite s'il te plaît.

gom · Optimisation

Malheureusement :

a/ impossible --> plus de place disque dans le SAN
b/ impossible --> même raison !

c/ C'est ce que je vais effectivement être obligé de faire

Que pensez-vous de :

DROP INDEX IF EXISTS mon_idx1;
DROP INDEX IF EXISTS mon_idx2;

VACUUM FULL ANALYSE;

CREATE INDEX mon_idx_1;
CREATE INDEX mon_idx_2;

Parce que "In fact, it is often faster to drop all indexes, VACUUM FULL, and recreate the indexes.", lu ici : http://www.postgresql.org/docs/8.4/stat … acuum.html.

Gôm

gom · Optimisation

Oui, à 282Go/300Go.

gom · Optimisation

Merci de me répondre !

/var/lib/postgresql/main/base/tablespaces/PRD/PRD_DWH/FACT/INDEX

Gôm

gom · Optimisation

Bonjour,

Je travaille sur un entrepôt de données sous PostgreSQL 8.4.4 (sous Redhat 5.4 64 bits).

J'ai un traitement automatique (dans l'ETL de Business Objects : "BO Data Integrator") qui lance les commandes SQL suivantes tous les weekends car j'alimente mon entrepôt de données le vendredi et j'ai besoin que mon entrepôt soit "propre" pour que mes utilisateurs puissent requêter via Business Objects (jusqu'au vendredi suivant : prochaine alimentation).

Script SQL :

print('<===============================================>');
print('\=== Début Instructions Exploitation');
print('  ==> Vacuum DWH');
print('<===============================================>');

$Resultat = sql('PRD_DWH', 'VACUUM ANALYZE VERBOSE');

print('<===============================================>');
print('  ==> Vacuum ODS');
print('<===============================================>');

$Resultat = sql('PRD_ODS', 'VACUUM ANALYZE VERBOSE');

print('<===============================================>');
print('  ==> Reindex DWH');
print('<===============================================>');

$Resultat = sql('PRD_DWH', 'REINDEX DATABASE "DWH"');

print('<===============================================>');
print('\=== Fin Instructions Exploitation : Ok');
print('<===============================================>');

Trace Error :

(11.7) 02-19-11 19:32:09 (E) (6120:4504) DBS-070404: |Session Job_Ordo_Exploit
                                                     SQL submitted to ODBC data source <DWH Linux> resulted in error <ERROR: could not extend relation
                                                     pg_tblspc/16395/16400/59020: wrote only 4096 of 8192 bytes at block 1700627;
                                                     Error while executing the query>. The SQL submitted is <REINDEX DATABASE "DWH">.
 (11.7) 02-19-11 19:32:09 (E) (6120:4504) RUN-050304: |Session Job_Ordo_Exploit
                                                     Function call <sql ( PRD_DWH, REINDEX DATABASE "DWH" ) > failed, due to error <70404>: <SQL submitted to ODBC data
                                                     source <DWH Linux> resulted in error <ERROR: could not extend relation pg_tblspc/16395/16400/59020: wrote only 4096 of
                                                     8192 bytes at block 1700627;
                                                     Error while executing the query>. The SQL submitted is <REINDEX DATABASE "DWH">.>.

J'ai constaté en monitorant mon serveur Linux (Redhat) que l'espace disque saturait à 282,... Go alors que j'ai bien 300 Go de disponible ?! 300 Go de dédié à mon répertoire "var/lib/postgresql/main/base".

Pourquoi mon réindexage ne continue pas jusqu'au 300 Go ? Mes Tablespaces ne sont pas censés s'étendre "jusqu'à l'infini" ?

Comment se fait-il que le REINDEX crée de l'écriture sur disque jusqu'à la fin du réindexage ? Je pensais que cela allait osciller d'un réindexage d'une table à un autre ?

Gôm qui comme vous l'aurez compris ... n'a toujours pas eu la formation PostgreSQL demandée !

gom · PL/pgSQL

Aïe ... j'ai 3 critères discriminants et chacun porte sur une table différente ! Je crois que je suis bloqué, je ne vais pas pouvoir faire mieux concernant le temps d'exécution de cette requête.

Quoi que ... je crois me rappeler que tu m'avais parlé de la possibilité de créer un Index sur lequel on ajoutait un critère, non ?

Je m'explique ...

mon_schema.gtin.gencode NOT LIKE '%000000'

Suite à la mise en place d'une nouvelle règle métier au sein de l'application qui s'appuie sur mon entrepôt de données, il faut toujours que ce critère soit ajouté à toutes les requêtes qui utilisent la table "gtin". N'est-il pas possible que ce critère discriminant soit "forcé" sans pour autant être mis systématiquement dans la clause "WHERE" ?

Je pense justement à ce que tu m'avais expliqué sur les Index avec conditions ... me gourais-je complètement ?!

Gôm

gom · PL/pgSQL

Résout un problème mais en créer (ou fait apparaître) un autre :

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

explain.depesz.com a écrit :

HashAggregate (cost=673404.59..673525.26 rows=3218 width=82) (actual time=341560.831..342227.067 rows=363524 loops=1)
-> Hash Join (cost=4463.19..673267.82 rows=3218 width=82) (actual time=465.039..340202.721 rows=363524 loops=1)
Hash Cond: (gtin.cod_tmarq = type_marque.cod_tmarq)
-> Hash Join (cost=4462.10..673221.57 rows=3462 width=83) (actual time=457.420..339759.613 rows=381684 loops=1)
Hash Cond: ((gtin.aacc_number)::text = (ref_accords.aacc_numero)::text)
-> Nested Loop (cost=0.00..668541.01 rows=12256 width=82) (actual time=79.743..337961.877 rows=1209316 loops=1)
-> Nested Loop (cost=0.00..612224.71 rows=17820 width=57) (actual time=51.770..130110.709 rows=4067925 loops=1)
-> Index Scan using calendrier_anneesem_idx on calendrier (cost=0.00..20.47 rows=15 width=27) (actual time=12.188..12.198 rows=5 loops=1)
Index Cond: (((anneesem)::text >= '2010S09'::text) AND ((anneesem)::text <= '2010S13'::text))
-> Index Scan using vte_hbd_a_s_idx on vte_hbd (cost=0.00..40525.33 rows=23063 width=46) (actual time=10.479..25410.726 rows=813585 loops=5)
Index Cond: (((vte_hbd.anneesem)::text >= '2010S09'::text) AND ((vte_hbd.anneesem)::text <= '2010S13'::text) AND ((vte_hbd.anneesem)::text = (calendrier.anneesem)::text))
-> Index Scan using gtin_idx on gtin (cost=0.00..3.15 rows=1 width=39) (actual time=0.049..0.049 rows=0 loops=4067925)
Index Cond: ((gtin.gencode)::text = (vte_hbd.gtin)::text)
Filter: ((gtin.gencode)::text !~~ '%000000'::text)
-> Hash (cost=4336.48..4336.48 rows=10050 width=44) (actual time=362.980..362.980 rows=10602 loops=1)
-> Seq Scan on ref_accords (cost=0.00..4336.48 rows=10050 width=44) (actual time=3.910..354.297 rows=10602 loops=1)
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) (actual time=7.604..7.604 rows=4 loops=1)
-> Seq Scan on type_marque (cost=0.00..1.04 rows=4 width=7) (actual time=7.596..7.599 rows=4 loops=1)
Total runtime: 342332.099 ms

gom · PL/pgSQL

Marc Cousin a écrit :

Peut être qu'en rajoutant cette information à la requête, les performances seraient meilleures ?

Comment puis-je ?

gom · PL/pgSQL

Peut-être devrais-je créer un Index qui inclus également mon champ "gtin" étant donné qu'il fait également partie de la jointure ?

-- Index: mon_schema.vte_hbd_idx_2

-- DROP INDEX mon_schema.vte_hbd_idx_2;

CREATE INDEX vte_hbd_idx_2
  ON mon_schema.vte_hbd
  USING btree
  (gtin, anneesem)
TABLESPACE "TBS_FACT_INDEX_F";

#76 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 16:56:01

#77 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 16:38:24

#78 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 16:23:26

#79 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 16:05:33

#80 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 15:37:50

#81 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 15:23:06

#82 Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 14:54:55

#83 Re : Optimisation » Optimisation d'un serveur dédié PostgreSQL avec 2 instances ? » 04/03/2011 17:47:17

#84 Re : Optimisation » Optimisation d'un serveur dédié PostgreSQL avec 2 instances ? » 04/03/2011 17:28:42

#85 Re : Optimisation » Optimisation d'un serveur dédié PostgreSQL avec 2 instances ? » 04/03/2011 17:02:22

#86 Re : Optimisation » Optimisation d'un serveur dédié PostgreSQL avec 2 instances ? » 04/03/2011 14:35:11

#87 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 04/03/2011 11:14:17

#88 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 04/03/2011 11:05:16

#89 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 04/03/2011 10:35:47

#90 Re : Optimisation » Optimisation d'un serveur dédié PostgreSQL avec 2 instances ? » 04/03/2011 10:00:36

#91 Optimisation » Optimisation d'un serveur dédié PostgreSQL avec 2 instances ? » 03/03/2011 16:49:29

#92 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 25/02/2011 21:02:22

#93 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 25/02/2011 19:39:01

#94 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 25/02/2011 19:24:44

#95 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 25/02/2011 19:20:35

#96 Optimisation » Plantage REINDEX par manque d'espace disque » 25/02/2011 16:35:14

#97 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 04/05/2010 09:35:23

#98 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 03/05/2010 15:07:17

#99 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 03/05/2010 13:56:39

#100 Re : PL/pgSQL » Index plus pris en compte si utilisation de fonctions ?! » 03/05/2010 09:46:01

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux