PostgreSQL Indice De L'Analyse De L'Utilisation

Est-il un outil ou une méthode pour analyser Postgres, et de déterminer ce que l'absence d'index doit être créé, et ce qui les index inutilisés doivent être supprimés? J'ai un peu d'expérience de le faire avec le "profiler" outil pour SQLServer, mais je ne suis pas au courant d'un outil similaire inclus avec Postgres.

Il en est ainsi. N'ai pas regardé ça de temps en temps. Mise à jour de mes accepté de répondre.

InformationsquelleAutor Cerin | 2010-07-23

153

J'aime pour trouver des index manquants:
```
SELECT
  relname                                               AS TableName,
  to_char(seq_scan, '999,999,999,999')                  AS TotalSeqScan,
  to_char(idx_scan, '999,999,999,999')                  AS TotalIndexScan,
  to_char(n_live_tup, '999,999,999,999')                AS TableRows,
  pg_size_pretty(pg_relation_size(relname :: regclass)) AS TableSize
FROM pg_stat_all_tables
WHERE schemaname = 'public'
      AND 50 * seq_scan > idx_scan -- more then 2%
      AND n_live_tup > 10000
      AND pg_relation_size(relname :: regclass) > 5000000
ORDER BY relname ASC;
```
Ce vérifie si il y a plus de séquence de scans de l'indice, puis les scans. Si la table est petite, elle est ignorée, car Postgres semble préférer la séquence d'analyses pour eux.

Requête ci-dessus fait apparaître l'absence d'index.

La prochaine étape serait de détecter des manque combiné index. Je suppose que ce n'est pas facile, mais faisable. Peut-être en analysant les requêtes lentes ... j'ai entendu pg_stat_statements pourrait aider...
- Pour faire ce travail avec des identificateurs entre guillemets modifier la requête pour: SELECT relname, seq_scan-idx_scan AS too_much_seq, case when seq_scan-idx_scan>0 THEN 'Missing Index?' ELSE 'OK' END, pg_relation_size(relid::regclass) AS rel_size, seq_scan, idx_scan FROM pg_stat_all_tables WHERE schemaname='public' AND pg_relation_size(relid::regclass)>80000 ORDER BY too_much_seq DESC;
- Le résultat de cette requête doit être expliqué pour rendre la réponse la plus utile
- À @cen 's point, quand too_much_seq est positif et important, vous devriez être concernés.
- J'ai créé quelques indices sur l'une des tables, mais encore, cette requête montrant les index manquants sur la table.
- Je suppose que les stats dans postgres contiennent encore les requêtes qui ont été exécutés avant la mise à jour de votre index. En fonction de votre trafic, vos stats seront de nouveau sur ok après quelques heures.
InformationsquelleAutor guettli
19

Consulter les statistiques. pg_stat_user_tables et pg_stat_user_indexes sont ceux pour commencer.

Voir "Le Collecteur Des Statistiques".

InformationsquelleAutor Frank Heikens
8

Sur la déterminer l'absence d'index approche....Nope. Mais il y a certains plans pour rendre cela plus facile à l'avenir de presse, comme des pseudo-indices et lisible à la machine EXPLIQUER.

Actuellement, vous aurez besoin de EXPLAIN ANALYZE pauvres de l'exécution des requêtes manuellement, puis déterminer le meilleur itinéraire. Certains analyseurs de log comme pgFouine peut aider à déterminer les requêtes.

Aussi loin qu'un index inutilisé, vous pouvez utiliser quelque chose comme ce qui suit pour vous aider à les identifier:
```
select * from pg_stat_all_indexes where schemaname <> 'pg_catalog';
```
Cela aidera à identifier les tuples lire, numérisé par les cheveux.
- Frank Heikens souligne également quelques bonnes adresses d'autres lieux pour interroger sur l'index en cours d'utilisation.
InformationsquelleAutor rfusca
7

Autre nouvelle intéressante outil pour l'analyse de PostgreSQL est PgHero. Il est plus axé sur l'optimisation de la base de données et fait de nombreuses analyses et suggestions.

InformationsquelleAutor n1000
3

Il y a plusieurs liens vers des scripts qui vous aidera à trouver des index inutilisés à la PostgreSQL wiki. La technique de base est de regarder pg_stat_user_indexes et recherchez ceux où idx_scan, le nombre de fois que cet indice a été utilisé pour répondre à des requêtes, est égal à zéro, ou au moins très faible. Si la demande a été modifiée et un autrefois utilisé l'indice n'est probablement pas maintenant, parfois, vous avez à courir pg_stat_reset() pour obtenir toutes les statistiques à 0, puis recueillir de nouvelles données; vous pouvez enregistrer les valeurs actuelles de tout et de calculer un delta au lieu de comprendre cela.

Il n'y a pas de bons outils pour suggérer l'absence d'index. Une approche consiste à connecter les requêtes que vous êtes en cours d'exécution et d'analyser ceux qui prennent du temps à s'exécuter à l'aide d'une requête journal de l'outil d'analyse comme pgFouine ou pqa. Voir "La Journalisation Difficile Requêtes" pour plus d'info.

L'autre approche est de regarder pg_stat_user_tables et de regarder pour les tables qui ont un grand nombre d'analyses séquentielles contre eux, où seq_tup_fetch est grande. Lorsqu'un index est utilisé le idx_fetch_tup nombre est augmenté à la place. Qui peut indice pour vous dans quand un tableau n'est pas indexé assez bien pour répondre à des requêtes.

Effectivement déterminer les colonnes à l'indice, puis sur? Qui habituellement conduit à la requête de l'analyse du journal des trucs encore.

InformationsquelleAutor Greg Smith

Vous pouvez utiliser la requête ci-dessous pour trouver l'Indice de l'utilisation et de la taille de l'Index:

Référence est prise à partir de ce blog.

SELECT
    pt.tablename AS TableName
    ,t.indexname AS IndexName
    ,to_char(pc.reltuples, '999,999,999,999') AS TotalRows
    ,pg_size_pretty(pg_relation_size(quote_ident(pt.tablename)::text)) AS TableSize
    ,pg_size_pretty(pg_relation_size(quote_ident(t.indexrelname)::text)) AS IndexSize
    ,to_char(t.idx_scan, '999,999,999,999') AS TotalNumberOfScan
    ,to_char(t.idx_tup_read, '999,999,999,999') AS TotalTupleRead
    ,to_char(t.idx_tup_fetch, '999,999,999,999') AS TotalTupleFetched
FROM pg_tables AS pt
LEFT OUTER JOIN pg_class AS pc 
    ON pt.tablename=pc.relname
LEFT OUTER JOIN
( 
    SELECT 
        pc.relname AS TableName
        ,pc2.relname AS IndexName
        ,psai.idx_scan
        ,psai.idx_tup_read
        ,psai.idx_tup_fetch
        ,psai.indexrelname 
    FROM pg_index AS pi
    JOIN pg_class AS pc 
        ON pc.oid = pi.indrelid
    JOIN pg_class AS pc2 
        ON pc2.oid = pi.indexrelid
    JOIN pg_stat_all_indexes AS psai 
        ON pi.indexrelid = psai.indexrelid 
)AS T
    ON pt.tablename = T.TableName
WHERE pt.schemaname='public'
ORDER BY 1;

InformationsquelleAutor Anvesh

1

PoWA semble être un outil intéressant pour PostgreSQL 9.4+. Il recueille des statistiques, visualise, et suggère des indices. Il utilise le pg_stat_statements extension.

PoWA est PostgreSQL Analyseur de Charge de travail qui rassemble les statistiques de performance et fournit en temps réel des graphiques et des diagrammes pour aider à contrôler et régler vos serveurs PostgreSQL. Il est semblable à Oracle AWR ou SQL Server MDW.

InformationsquelleAutor n1000
1

Il peut être trouvé en utilisant la requête suivante dans postgres console
```
use db_name
select * from pg_stat_user_indexes;
select * from pg_statio_user_indexes;
```
Pour Plus De Détails https://www.postgresql.org/docs/current/monitoring-stats.html

InformationsquelleAutor ShreePrakash

CREATE EXTENSION pgstattuple; 
CREATE TABLE test(t INT); 
INSERT INTO test VALUES(generate_series(1, 100000)); 
SELECT * FROM pgstatindex('test_idx'); 

version            | 2 
tree_level         | 2 
index_size         | 105332736 
root_block_no      | 412 
internal_pages     | 40 
leaf_pages         | 12804 
empty_pages        | 0 
deleted_pages      | 13 
avg_leaf_density   | 9.84 
leaf_fragmentation | 21.42

InformationsquelleAutor madjardi

-1

Cela devrait vous aider: Travaux Pratiques Analyse De La Demande De
- La dernière mise à jour de PQA est vieux de plusieurs années. Il a une fonctionnalité qui n'est pas pris en charge par pgFouine?
InformationsquelleAutor João Pereira

Vous devez vous connecter pour publier un commentaire.