Footcow Blog - Mot-clé - volumétrieLinux, Base de données Postgresql, développement, Internet, emailing et déliverabilité.2024-03-28T13:48:38+01:00Hervé Piedvache alias Bill Footcow pour les intimesurn:md5:ef5d07bad25e414feca607a3b7f2af11DotclearPostgreSQL : Vos index sont-ils utilisés ?urn:md5:4df46f64e306b0bd9cb1c5df09385cd92009-10-23T21:36:00+02:002009-10-23T21:36:00+02:00footcowPostgreSQLbase de donnéesindexpostgresltaillevolumétrie<p><br />
Pour compléter mon précédent billet sur <a href="https://www.footcow.com/index.php/post/2007/12/18/Lespace-disque-de-votre-base-de-donnees">L'espace disque de votre base de données</a>, il est également particulièrement intéressant d'être en mesure d'évaluer si les index volumineux sont véritablement utiles en production.
Un index peut être parfois coûteux en espace de stockage, mais savez-vous si il est véritablement pertinent pour votre applicatif en production ?</p> <p>Quoi de mieux qu'une simple requête pour vous permettre d'un seul coup d'oeil de connaître à la fois :</p>
<ul>
<li>le nom du schéma</li>
<li>le nom de la table concernée</li>
<li>le nom de l'index</li>
<li>le nombre d'utilisation de l'index</li>
<li>la taille de la table</li>
<li>la taille de l'index</li>
<li>le ratio entre la table et son index</li>
</ul>
<p>Exemple :</p>
<pre>
select
s.schemaname as sch,
s.relname as rel,
s.indexrelname as idx,
s.idx_scan as scans,
pg_size_pretty(pg_relation_size(s.relid)) as ts,
pg_size_pretty(pg_relation_size(s.indexrelid)) as "is",
(1.0 * pg_relation_size(s.indexrelid) / pg_relation_size(s.relid))::numeric(10, 2) as ratio
from
pg_stat_user_indexes s
join pg_index i on i.indexrelid=s.indexrelid
left join pg_constraint c on i.indrelid=c.conrelid and array_to_string(i.indkey, ' ') = array_to_string(c.conkey, ' ')
where
i.indisunique is false
and pg_relation_size(s.relid) > 1000000
and s.idx_scan < 100000
and c.confrelid is null
order by
CASE WHEN s.idx_scan < 1000 THEN 0 ELSE s.idx_scan END asc,
pg_relation_size(s.indexrelid) desc,
pg_relation_size(s.relid) desc;
</pre>
<p><strong>Attention</strong> cette requête d'exemple, ne prend en compte que des tables de plus 1 Mo, et les index qui n'ont été scannés que moins de 100 000 fois. Vous pouvez adapter les paramètres de pg_relation_size(s.relid) et idx_scan qui se trouvent dans le WHERE en fonction de vos besoins.</p>
<p>Résultat :</p>
<pre>
sch | rel | idx | scans | ts | is | ratio
--------+---------------------+-------------------------------------------------+-------+---------+------------+-------
public | table_name | ix_table_name | 0 | 24 MB | 16 MB | 0.68
</pre>
<p>On voit donc rapidement que si cet index (ix_table_name) est en production, il n'est à ce jour jamais utilisé, et coûte l'air de rien pas loin de 16 Mb d'espace inutile ... il est donc temps de se demander pourquoi il a été créé ...</p>
<p>Je remercie au passage <a href="https://twitter.com/luddic" hreflang="fr">Luddic</a> qui m'a fait partager son expérience sur ce sujet.</p>https://www.footcow.com/index.php/post/2009/10/23/PostgreSQL-%3A-Vos-index-sont-ils-utilis%C3%A9s#comment-formhttps://feeds.feedburner.com/FootcowBlog/comments/78L'espace disque de votre base de donnéesurn:md5:f944547ad1b7465d160330d3cf0716b12007-12-18T00:55:00+01:002017-11-24T16:44:57+01:00footcowPostgreSQLbase de donnéespostgresqltaillevolumétrie<p>Votre base de données est volumineuse ... vous voyez aisément l'espace utilisé par le répertoire qui stocke vos données, mais quand est-il d'une table en particulier ? Comment se rendre compte facilement du volume que représente ces millions de données que vous gérez au quotidien ? Votre espace disque de stockage principal commence sérieusement à s'amoindrir ... ne serait-il pas temps de créer un nouveau tablespace pour optimiser les accès sur un autre espace disque ?<br /></p>
<p>Des questions qui assurément vous sont venus un jour ou l'autre, et qui sont très faciles à connaître avec <a href="https://www.postgresql.org" hreflang="en">PostgreSQL</a>.<br /></p> <p><strong>Connaître le nombre d'octets utilisés pour stocker une valeur en particulier</strong> :<br /></p>
<pre>
base=# SELECT pg_column_size('1');
pg_column_size
----------------
2
</pre>
<pre>
base=# SELECT pg_column_size(1);
pg_column_size
----------------
4
</pre>
<p><strong>Connaître l'espace disque utilisé par une database complète :</strong><br /></p>
<pre>
base=# SELECT pg_database_size('base');
pg_database_size
------------------
128254784136
</pre>
<p><strong>Connaître l'espace disque utilisé sur un tablespace :</strong><br /></p>
<pre>
base=# SELECT pg_tablespace_size('data2');
pg_tablespace_size
--------------------
53866725380
</pre>
<p><strong>Connaître la taille d'une table ou d'un index par son nom :</strong><br /></p>
<pre>
base=# SELECT pg_relation_size('my_table');
pg_relation_size
------------------
10714234880
</pre>
<p><strong>Connaître la taille représentée par une table, en incluant toutes les données liées (index, toast) :</strong><br /></p>
<pre>
base=# SELECT pg_total_relation_size('my_table');
pg_total_relation_size
------------------------
24756928512
</pre>
<p>Naturellement les octets ne sont pas le moyen le plus facile de lire une représentation d'un volume de données, il existe heureusement la commande <code><strong>pg_size_pretty(int)</strong></code> qui permet d'obtenir des chiffres humainement lisibles :<br /></p>
<pre>
base=# SELECT pg_size_pretty(pg_total_relation_size('my_table'));
pg_size_pretty
----------------
23 GB
</pre>
<p>Enfin, une requête qui vous donne un rapide aperçu de l'ensemble de vos données ... à utiliser sans modération :<br /></p>
<pre>
SELECT schemaname, tablename, tablespace, pg_size_pretty(taille) AS taille_table, pg_size_pretty(taille_index), pg_size_pretty(taille_totale) AS taille_totale_table, pg_size_pretty(taille_totale - (taille_index + taille)) as toast_size
FROM (SELECT *,
pg_relation_size(schemaname || '.' || tablename) AS taille,
pg_total_relation_size(schemaname || '.' || tablename) AS taille_totale, pg_indexes_size(schemaname || '.' || tablename) as taille_index
FROM pg_tables) AS tables
ORDER BY taille_totale DESC;
</pre>https://www.footcow.com/index.php/post/2007/12/18/Lespace-disque-de-votre-base-de-donnees#comment-formhttps://feeds.feedburner.com/FootcowBlog/comments/35