Vous n'êtes pas identifié(e).
Bonjour,
Est ce que le nombre de tables présentes dans une base peut affecter les performances globales ? Quand je parle d'un grand nombre, c'est plusieurs dizaines de milliers.
Merci
Hors ligne
Bonjour,
Cela peut impacter les performances effectivement. Le premier problème qui risque d'arriver est une consommation de mémoire excessive si vous utilisez un pooler de connexion (ou des connexion persistentes), du fait que chaque connexion finira par avoir un cache de toutes les tables de la base;
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Cela peut impacter les performances effectivement. Le premier problème qui risque d'arriver est une consommation de mémoire excessive si vous utilisez un pooler de connexion (ou des connexion persistentes), du fait que chaque connexion finira par avoir un cache de toutes les tables de la base;
C'est intéressant... parce qu'effectivement, on utilise un pooler de connexion (pgbouncer)
Hors ligne
Plusieurs dizaines de milliers de tables...c'est énorme.
Je suis curieux de savoir...il y a quoi dans la base ?
Il n'y aurait pas un soucis de modélisation/analyse...
Dernière modification par genamiga (19/04/2019 17:28:32)
Hors ligne
C'est possible, mais pas systématique. Cela peut être un système multi-tenant ave un découpage par schéma par exemple, et/ou une ou plusieurs tables partitionnées avec beaucoup de partitions. Le fait est que postgres 12 aura énormément d'optimisations afin de conserver des performances raisonnables avec un très grand nombre de partititions, justement parce que ce besoin est fréquent.
Julien.
https://rjuju.github.io/
Hors ligne
Oui, c'est à peu près cela, on est dans un contexte multi tenant, on a des centaines de clients, des tables de travails,..... et on ne supprime jamais les données des clients mêmes s'ils ne sont plus chez nous. La modélisation est correcte de mon point de vue mais la question du sharding se pose sérieusement en interne si vous voulez tout savoir 
Hors ligne
Aujourd'hui, la table pg_class fait presque 800M.
Faut'il envisager des reindexations/vacuum fulls des tables systèmes ?
Hors ligne
En effet, ça devrait être envisageable....
toto=# SELECT * FROM pgstattuple('pg_catalog.pg_class');
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
799973376 | 91327 | 16253259 | 2.03 | 197115 | 33824913 | 4.23 | 724299904 | 90.54
Hors ligne
Vous utilisez beaucoup de tables temporaires ?
Guillaume.
Hors ligne
Vous utilisez beaucoup de tables temporaires ?
Oui... à haute dose.
Hors ligne
Alors oui, un vacuum full des tables systèmes s'impose, et des vacuum très réguliers pour éviter que la situation ne se reproduise.
Julien.
https://rjuju.github.io/
Hors ligne
Pour expliquer, la création de la table temporaire crée une ligne dans pg_class, autant de lignes dans pg_attribute que de colonnes dans la table temporaire, et potentiellement d'autres catalogues systèmes. Et dès la destruction de cette table, ces lignes sont supprimées. Donc si vous utilisez beaucoup les tables temporaires, il y a de forte chance que cela fragmente beaucoup les catalogues systèmes.
Guillaume.
Hors ligne
Quel est l'impact d'un vacuum full sur une table système ? Est ce que ça va bloquer toute l'activité de la base ?
Hors ligne
Tout dépend de la table système et de l'activité. Pour pg_class et pg_attribute, comme cela empêchera l'accès à ces tables durant le temps du VACUUM FULL, cela empêchera au minimum :
- toute nouvelle connexion
- toute requête accédant à une table n'ayant pas été accédée auparavant au sein de la même sessions (car il n'y a pas d'entrée en cache pour cette table)
Cela dit, même avec plusieurs dizaine de milliers de tables, le VACUUM FULL de pg_class et pg_attribute devrait quand même être très rapide.
Julien.
https://rjuju.github.io/
Hors ligne
Le blocage de nouvelles connexions, c'est quand même assez pénalisant....
Est ce que si je laisse en l'état, je fonce droit vers des ennuis ? Je ne vous cache pas que faire une action comme cela sur des tables systèmes ne m'enchante guère....c'est pas que je n'ai pas confiance en PG, mais s'il y a un problème, c'est toute la base qui risque de se trouver par terre...
Du coup, une nouvelle question m'est venue: est ce qu'il est possible de backuper et surtout restaurer la table pg_class ?
Hors ligne
Oui, enfin on parle quand même d'un délai de l'ordre de quelques dizaines ou centaines de millisecondes.
En cas de problème, tout ne se retrouve pas par terre. Il suffit d'annuler la requête (et la transaction), et tout reprend comme avant.
On ne peut pas backuper la table pg_class, elle n'est que la représentation des objets créés. Elle est donc mise à jour avec chaque commande DDL effectuée.
Julien.
https://rjuju.github.io/
Hors ligne
