Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#126 Re : Général » pg_buffercache » 22/08/2012 16:38:00
Oui, on a migré la 8.3 en 9.1.
#127 Re : Général » pg_buffercache » 22/08/2012 16:12:54
QUand je cree l'extension, j'ai un message d'erreur, quand je la drop j'ai aussi un message d'erreur :
DB600=# CREATE EXTENSION pg_buffercache;
ERROR: function "pg_buffercache_pages" already exists with same argument types
DB600=# DROP EXTENSION pg_buffercache;
ERROR: extension "pg_buffercache" does not exist
DB600=#
#128 Re : Général » BitmapAnd » 22/08/2012 13:56:53
Merci bcp julien !
#129 Re : Général » BitmapAnd » 22/08/2012 11:25:35
Ok, je vais ressayer encore le IN à la place du ANY.
Que fait exactement cette ligne :
Append (cost=0.00..138929.52 rows=2747 width=0) (actual time=138070.950..437390.474 rows=3653 loops=1)
Je ne comprends pas l'uitilité du Append.
Une auttre question :
Postgres utilise des bloc de 8 ko, est-ce-qu'il faut remplir les blocs ou bien laiseer une partie vide au cas où y aurai un update, comme ça la nouvelle ligne soit dans le meme bloc que l'ancienne.
Serait-il possible de modifier le paramètre default_statistics_target pour une table donnée ?
#130 Général » BitmapAnd » 21/08/2012 18:14:35
- Postgres.0
- Réponses : 4
Bonjour,
j'ai un problème avec cette requette, quelqu'un a t'il une idée pour aider à comprendre le comportement de ce planificateur et surtout l'améliorer.
Un truc très bizarre, c'est que le BitmapAnd ramène 0 lignes alors que le Bitmap Heap Scan lui ramène un nombre de ligne =1720.
Hometal=# explain analyze SELECT count(*) FROM aus.fintrac
WHERE date_transaction between '2012-02-29 00:00:00' and '2012-03-01 23:59:59'
AND idc = 196
AND id_org = ANY '{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}')
AND id_type = ANY( '{4}' ) ;
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=138936.39..138936.40 rows=1 width=0) (actual time=437393.828..437393.828 rows=1 loops=1)
-> Append (cost=0.00..138929.52 rows=2747 width=0) (actual time=138070.950..437390.474 rows=3653 loops=1)
-> Index Scan using fintrac_ndx2 on fintrac (cost=0.00..4.36 rows=1 width=0) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: (idc = 196)
Filter: ((id_type = ANY ('{4}'::smallint[])) AND (date_transaction >= '2012-02-29 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-01 23:59:59'::timestamp without time zone) AND (id_org = ANY ('{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}'::integer[])))
-> Bitmap Heap Scan on par_fintrac_2012_02 fintrac (cost=21733.75..68140.80 rows=1365 width=0) (actual time=138070.933..200613.841 rows=1933 loops=1)
Recheck Cond: ((date_transaction >= '2012-02-29 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-01 23:59:59'::timestamp without time zone) AND (id_org = ANY ('{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}'::integer[])))
Filter: ((id_type = ANY ('{4}'::smallint[])) AND (idc = 196))
-> BitmapAnd (cost=21733.75..21733.75 rows=23285 width=0) (actual time=128014.793..128014.793 rows=0 loops=1)
-> Bitmap Index Scan on par_fintrac_2012_02_ndx1 (cost=0.00..9665.01 rows=432131 width=0) (actual time=4152.068..4152.068 rows=418206 loops=1)
Index Cond: ((date_transaction >= '2012-02-29 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-01 23:59:59'::timestamp without time zone))
-> Bitmap Index Scan on par_fintrac_2012_02_ndx3 (cost=0.00..12067.81 rows=632219 width=0) (actual time=123725.475..123725.475 rows=704808 loops=1)
Index Cond: (id_org = ANY ('{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}'::integer[]))
-> Bitmap Heap Scan on par_fintrac_2012_03 fintrac (cost=22877.18..70784.35 rows=1381 width=0) (actual time=177594.088..236774.372 rows=1720 loops=1)
Recheck Cond: ((date_transaction >= '2012-02-29 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-01 23:59:59'::timestamp without time zone) AND (id_org = ANY ('{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}'::integer[])))
Filter: ((id_type = ANY ('{4}'::smallint[])) AND (idc = 196))
-> BitmapAnd (cost=22877.18..22877.18 rows=23980 width=0) (actual time=176786.846..176786.846 rows=0 loops=1)
-> Bitmap Index Scan on par_fintrac_2012_03_ndx1 (cost=0.00..9651.17 rows=447937 width=0) (actual time=3576.379..3576.379 rows=460007 loops=1)
Index Cond: ((date_transaction >= '2012-02-29 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-01 23:59:59'::timestamp without time zone))
-> Bitmap Index Scan on par_fintrac_2012_03_ndx3 (cost=0.00..13225.07 rows=716892 width=0) (actual time=173106.841..173106.841 rows=812583 loops=1)
Index Cond: (id_org = ANY ('{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}'::integer[]))
Total runtime: 437395.251 ms
(22 rows)#131 Re : Général » pg_buffercache » 21/08/2012 12:31:18
Merci beaucoup
#132 Re : Général » pg_buffercache » 21/08/2012 12:14:27
C'est tout !!!
C'est quoi une extension ?
Et si je ne veut plus de ce module , je suppose que je dois faire "DROP EXTENSION pg_buffercache;".
#133 Général » pg_buffercache » 21/08/2012 11:58:11
- Postgres.0
- Réponses : 7
Bonjour,
je suis sur la 9.1, j'aimerai installer le module contrib de pg_buffercache.
Alors j'ai fait cd /usr/pgsql-9.1/share/extension/
ls -lrt *pg_buf*
-rw-r--r--. 1 root root 335 Jun 4 00:19 pg_buffercache--unpackaged--1.0.sql
-rw-r--r--. 1 root root 157 Jun 4 00:19 pg_buffercache.control
-rw-r--r--. 1 root root 755 Jun 4 00:19 pg_buffercache--1.0.sql
Je ne sais pas à quoi servent les trois fichiers, le quel dois-je installer et comment?
Et pour desinstaller ce module, je n'ai pas vu de fichier uninstall_pg_buffercache.sql comme dans la 8.4.
#134 Re : Général » problèmes avec les STAS » 10/08/2012 14:58:43
PG dois se dire qu'il est dans une partition faite en fonction de date_transaction, et donc ce n'est pas la peine de l'utiliser dans l'iindex.
#135 Re : Général » problèmes avec les STAS » 10/08/2012 14:57:02
Vous avez raison, il n'a pas utilisé l'index11 (id_org,date_transaction,is_offline), mais il as utilisé juste cet index sur id_org et is_offline.
Je pensais tout simplement que ce n'était pas possible.
#136 Re : Général » problèmes avec les STAS » 10/08/2012 12:04:37
Le temps d'exécution passe de 4 min à 2 min en mettant à jour les statistiques, donc si, ça sera meilleur. Pas forcément les perfs que vous attendez, mais meilleur.
Pour les améliorer encore plus, le gros soucis de vos perfs vient surtout de ça : Buffers: shared hit=146 read=661450. Lecture sur disque de 661450 blocs, soit 5,1 Go sur disque en 2 min 40. Comme le dit rjuju, c'est très étonnant que les données ne tiennent pas en mémoire. En tout cas, PostgreSQL ne les a pas dans son cache et il semblerait que le système non plus. Cette partition ne ferait pas justement dans les 5 Go justement ?
Un index sur les trois colonnes (id_org, is_offline, date_transaction) pourrait peut-être améliorer les choses. À tester.
Bonjour gleu,
j'ai créé un index sur (id_org,date_transaction,is_offline), et les perfs sont améliorées.
Je vous mets le nouveau plan d'exécution.
Hash Join (cost=289.87..143373.45 rows=29072 width=775) (actual time=396.318..115782.691 rows=39071 loops=1)
Hash Cond: (ft.id_org = os.id_org)
Buffers: shared hit=189 read=42470
-> Append (cost=0.00..142429.47 rows=29072 width=763) (actual time=370.332..115660.991 rows=39071 loops=1)
Buffers: shared hit=187 read=42369
-> Seq Scan on ftransac ft (cost=0.00..0.00 rows=1 width=1996) (actual time=5.618..5.618 rows=0 loops=1)
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text) AND (id_org = ANY ('{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}'::integer[])))
-> Bitmap Heap Scan on par_ftransac_2012_03 ft (cost=20115.05..142429.47 rows=29071 width=763) (actual time=364.713..115636.834 rows=39071 loops=1) Recheck Cond: (id_org = ANY ('{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}'::integer[]))
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text))
Buffers: shared hit=187 read=42369
-> Bitmap Index Scan on par_ftransac_ndx11 (cost=0.00..20107.79 rows=32809 width=0) (actual time=342.191..342.191 rows=39071 loops=1)
Index Cond: ((id_org = ANY ('{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}'::integer[])) AND (is_offline = true))
Buffers: shared hit=187 read=4082
-> Hash (cost=184.94..184.94 rows=8394 width=16) (actual time=25.924..25.924 rows=8394 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 410kB
Buffers: shared read=101
-> Seq Scan on org os (cost=0.00..184.94 rows=8394 width=16) (actual time=18.627..23.660 rows=8394 loops=1)
Buffers: shared read=101
Total runtime: 115795.459 ms#137 Re : Général » problèmes avec les STAS » 09/08/2012 14:00:02
Merci beaucoup, je comprends maintenant.
#138 Re : Général » problèmes avec les STAS » 09/08/2012 11:53:45
3. Il utilise l'index Btree et crée en mémoire un index Bitmap. Il fait un IndexScan quand il y a très peu de lignes à lire, il fait un BitmapIndexScan quand le nombre de lignes est plus important, et il fait un SeqScan quand il y a beaucoup de lignes à lire.
C'est justement la où ce n'est pas clair :
un B-tree c'est un arbre dynamique equilibré et le bit-map est un tableau à deux dimensions. Je ne vois pas l'interêt de creer un index-Btree et puis se servir uniquement d'un bitmap en mémoire.
1. Je ne comprends pas la question.
Ma question concerne l'itulisation du bit-map :
comment à partir du bit-map en mémoire, il va chercher les lignes de la table ou les blocs ?
Le heap scan, c'est quoi?
#139 Re : Général » problèmes avec les STAS » 09/08/2012 10:58:48
Merci, je vais abuser une dernière fois
rjuju
1 . quelle est la bonne formule :
a) work_meme*nbr_connexion + shared_buffer + nbr_connexion*maintenance_work_mem < taille_memoire_totale
b) work_meme*nbr_connexion + shared_buffer + nbr_connexion*maintenance_work_mem + effective_cache_size < taille_memoire_totale.
2. est-t-il vrai que le shared buffer est inclus dans le effective_cache_size.
3. pour quoi quand je crée un index B-tree, postgres dans le plan d'execution me cree toujours un index bitmap.
gleu
1. j'ai vu que plusieurs fois sur ce forum que vous disiez "en gros" que Bitmap Index Scan construit l'index Bitmap qui servira à parcourir la table pour retrouver les bonnes lignes ( Bitmap Heap Scan).
Pouvez vous s-il vous plait expliquez un peu plus en détail, sachant que pour ce genre d'index postgres est censé tenir compte de la cardinalité des valeurs de la colonne indexée.
Ce qui n'est pas le ca pour ma requête.
2 Mar cousin disais "effective_cache_size aide PostgreSQL à estimer la probabilité qu'une donnée soit dans le cache système, ou y reste"
si je le mets par exemple à 8GB, je ne vois pas pourquoi les donnée seront dans le cache.
merci et désolé pour ces spams.
#140 Re : Général » problèmes avec les STAS » 08/08/2012 19:02:35
Il faudrait donc que vous regardiez si en lançant 2 fois l'explain analyze sans redémarrer postgres ni vider le cache amènent bien à un gain de performances conséquent.
Je l'ai fait est ça donne Total runtime: 2061.855 ms.
C'est clairement un gain enorme.
Sauf que ce n'est pas la réalité :
Ce qui est intéréssant, c'est que la requete retourne des resultat acceptable la première fois.
Donc, je repose s'il vous plait ma question :
Pourquoi c'est pas normal que les données soient lues sur le disque, quand je lance ma requete pour la première fois.
Merci.
#141 Re : Général » problèmes avec les STAS » 08/08/2012 18:29:49
Y a t-il une piste pour savoir pourquoi les données ne tiennent pas en mémoire
Non, on ne peut pas répondre à cette question à partir de cet EXPLAIN. Nous ne savons pas comment est utilisé la machine, s'il y a d'autres serveurs (PostgreSQL ou non), s'il y a beaucoup d'utilisateurs, si même les données sont réellement lues sur le disque et pas dans le cache du système d'exploitation. Très difficile de deviner ça à distance.
il n y a qu'un seul serveur postgres sur la machine.
Avant le lancement de la requete, je netoie le cache systeme d'exploitation et le cache postgres.
"echo 3 > /proc/sys/vm/drop_caches; /etc/init.d/postgresql-9.1 restart"
il y a au Max 10 connexion sur Postgres.
#142 Re : Général » problèmes avec les STAS » 08/08/2012 18:22:07
Expliquez moi s'il vous plait pourquoi les données doivent êre dans le cache.
Dans une base, les données sont bien sur le disque, alors on me dit que c'est tout à fait normal qu'on aie chercher les données sur dique.
#143 Re : Général » problèmes avec les STAS » 08/08/2012 18:17:42
Y a t-il une piste pour savoir pourquoi les données ne tiennent pas en mémoire.
#144 Re : Général » problèmes avec les STAS » 08/08/2012 18:16:40
SELECT pg_size_pretty (pg_relation_size('aus.par_ftransac_2012_03)) donne 18 GB
et SELECT pg_size_pretty (pg_total_relation_size('ausemv.par_financial_transaction_2012_03')) donne 20GB
#145 Re : Général » problèmes avec les STAS » 08/08/2012 17:47:13
Je vais demander à la PROD pourquoi il désactive l'autovacuum.
Au fait la base est-une base dans laquelle y a beaucou d'INSERT d'UPDATE et de SELECTS.
Mais même si je réactive l'autovacuum, le temps d'exécution ne sera pas meilleur.
#146 Re : Général » problèmes avec les STAS » 08/08/2012 17:23:12
j'ai fait "cat /proc/meminfo" pour avoir les 28GB de la mémoire.
Comment pouvez vous savoir que les données sont lues sur le disque ?
Avez des pistes pour savoir pourquoi il lit les donées sur le disque.
Autovacuum est désactivé par la PROD, si je le reactive en DEV, je ne serai pas dans les mêmes conditions qu'en PROD.
#147 Re : Général » problèmes avec les STAS » 08/08/2012 17:07:16
Oui effectivement l'autovacuum est désactivé (j'ai pas le choix car en PROD il est désactivé aussi).
Comment je peux faire pour calculer plus frequemment les statistics.
est-il pértinent de cibler quelques colonnes par des calculs de stats ?
Faut-il indexer autrement ?
voici le plan avec l'option BUFFER on du EXPLAIN ANALYZE :
Hash Join (cost=289.87..1561748.27 rows=28517 width=775) (actual time=1066.060..254907.763 rows=39071 loops=1)
Hash Cond: (ft.id_org = os.id_org)
Buffers: shared hit=148 read=661551
-> Append (cost=0.00..1560816.77 rows=28517 width=763) (actual time=1049.268..254811.975 rows=39071 loops=1)
Buffers: shared hit=146 read=661450
-> Seq Scan on ftransac ft (cost=0.00..0.00 rows=1 width=1996) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text) AND (id_org = ANY ('{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}'::integer[])))
-> Bitmap Heap Scan on par_ftransac_2012_03 ft (cost=12391.03..1560816.77 rows=28516 width=763) (actual time=1049.264..254798.861 rows=39071 loops=1)
Recheck Cond: (id_org = ANY ('{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}'::integer[]))
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text))
Buffers: shared hit=146 read=661450
-> Bitmap Index Scan on par_ftransac_2012_03_ndx3 (cost=0.00..12383.90 rows=672761 width=0) (actual time=816.328..816.328 rows=812583 loops=1)
Index Cond: (id_org = ANY ('{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}'::integer[]))
Buffers: shared hit=145 read=2281
-> Hash (cost=184.94..184.94 rows=8394 width=16) (actual time=16.736..16.736 rows=8394 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 410kB
Buffers: shared read=101
-> Seq Scan on org os (cost=0.00..184.94 rows=8394 width=16) (actual time=9.091..14.467 rows=8394 loops=1)
Buffers: shared read=101
Total runtime: 254918.304 ms
.#148 Re : Général » problèmes avec les STAS » 08/08/2012 16:25:04
Même si il est meilleur que l'autre il faut que je l'amiliore.
Et puis bizarrement la requête sur les stat donne des resultats maintenant.
Comment pourrais-je faire pour améliorer les perfs de cette requette.
#149 Re : Général » problèmes avec les STAS » 08/08/2012 16:15:26
Après avoir fait un analyze, voila le nouveau plan d'exécution :
Hash Join (cost=289.87..1561748.27 rows=28517 width=775) (actual time=1063.749..170240.572 rows=39071 loops=1)
Hash Cond: (ft.id_org = os.id_org)
-> Append (cost=0.00..1560816.77 rows=28517 width=763) (actual time=1046.972..170140.773 rows=39071 loops=1)
-> Seq Scan on ftransac ft (cost=0.00..0.00 rows=1 width=1996) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text) AND (id_org = ANY ('{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}'::integer[])))
-> Bitmap Heap Scan on par_ftransac_2012_03 ft (cost=12391.03..1560816.77 rows=28516 width=763) (actual time=1046.968..170130.653 rows=39071 loops=1)
Recheck Cond: (id_org = ANY ('{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}'::integer[]))
Filter: (is_offline AND (date_transaction >= '2012-03-01 00:00:00'::timestamp without time zone) AND (date_transaction <= '2012-03-31 23:59:59'::timestamp without time zone) AND (id_client = 196) AND ((cashier)::text = '00000001'::text))
-> Bitmap Index Scan on par_ftransac_2012_03_ndx3 (cost=0.00..12383.90 rows=672761 width=0) (actual time=812.923..812.923 rows=812583 loops=1)
Index Cond: (id_org = ANY ('{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}'::integer[]))
-> Hash (cost=184.94..184.94 rows=8394 width=16) (actual time=16.707..16.707 rows=8394 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 410kB
-> Seq Scan on org os (cost=0.00..184.94 rows=8394 width=16) (actual time=9.120..14.528 rows=8394 loops=1)
Total runtime: 170251.452 ms#150 Re : Général » problèmes avec les STAS » 08/08/2012 15:48:38
Bonjour,
cela ressemble plutôt à un problème d'autorisation de l'utilisateur qui lance cette requête, à moins que vous n'ayez désactivé les paramètres track_* dans le postgresql.conf.Si vous avez un exemple de requête de plus en plus longue avec son explain analyze, cela aiderait à vous aider.
Edit: Effectivement je n'avais pas vu que le nom du schéma était passé dans le tablename
Je n'ai pas bien compri mais dans le .conf j'ai :
# - Query/Index Statistics Collector -
#track_activities = on
#track_counts = on
#track_functions = none # none, pl, all
#track_activity_query_size = 1024 # (change requires restart)
#update_process_title = on
#stats_temp_directory = 'pg_stat_tmp'