Recommandations de performance pour la base de données (par Azure PSQL)

Dev
1

Bonjour,

Nous hébergeons notre forum basé sur Discourse sur Azure avec une instance « Azure Database for PostgreSQL ». L’un des avantages de ce service est les recommandations de performance basées sur les « caractéristiques de la base de données » et l’utilisation.
Depuis notre migration vers Azure, nous avons reçu des indications concernant des index manquants et probablement redondants que je souhaite partager avec vous.
Nous avons observé une légère (mais minime) augmentation globale des performances après la création de ces index manquants, mais nous n’avons pas pu appliquer les recommandations DROP INDEX, car cela pourrait/risquerait de rompre les futures mises à jour ou migrations de base de données. Quoi qu’il en soit, nous ne pouvons pas déterminer si ces index sont sûrs à supprimer ou si leur suppression aura un impact négatif sur les performances.

Voici les index qu’Azure nous a suggérés de créer (impact « faible » et « modéré ») :
create-indexes.csv (1,5 Ko)

Voici les recommandations concernant les index « déjà couverts » :

Résumé

Supprimer l’index index_optimized_images_on_upload_id sur la table public.optimized_images.
Raison : L’index est couvert par index_optimized_images_on_upload_id_and_width_and_height.

Supprimer l’index index_post_revisions_on_post_id sur la table public.post_revisions.
Raison : L’index est couvert par index_post_revisions_on_post_id_and_number.

Supprimer l’index post_timings_summary sur la table public.post_timings.
Raison : L’index est couvert par post_timings_unique.

Supprimer l’index index_topic_links_on_topic_id sur la table public.topic_links.
Raison : L’index est couvert par unique_post_links.

Supprimer l’index index_post_uploads_on_post_id sur la table public.post_uploads.
Raison : L’index est couvert par idx_unique_post_uploads.

Vous devriez prendre ces recommandations de « SUPPRESSION » avec une certaine réserve, car je pense qu’elles n’affecteront que la taille globale de la base de données plutôt que d’améliorer les performances. Par exemple : notre base de données entière utilise environ 120 Go et toutes ces recommandations ne libéreront que 422 Mo. Azure lui-même définit l’impact comme « faible ». Il semble donc qu’il ne s’agisse que d’un nettoyage.

Comme mentionné ci-dessus, je voulais simplement partager cela avec vous, car cela pourrait aider à optimiser légèrement les performances. En dehors de ces index, Azure n’a fourni aucune autre recommandation depuis que nous utilisons leurs services.

Cordialement,
Sascha

2

Merci pour le partage, certaines des recommandations sont un peu étranges…

CREATE INDEX index_topics_on_category_id ON public.topics USING btree (category_id)
CREATE INDEX index_topics_on_category_id_and_id ON public.topics USING btree (category_id, id)
CREATE INDEX index_topics_on_id_and_category_id ON public.topics USING btree (category_id, id)

Cet index dupliqué en triple proposé a une sélectivité extrêmement faible. Le problème avec ce type d’index est que le planificateur a tendance à les ignorer correctement. S’il n’y a que 10 valeurs différentes, il faut les combiner avec autre chose, par exemple topic_id.

En ce qui concerne les indexes sous-utilisés, il y a environ 6 mois, nous avons exécuté des statistiques sur la base de données pour identifier les indexes que nous n’avions pas utilisés dans notre infrastructure. Nous en avons supprimé quelques-uns, mais ce sujet est un bon rappel pour nous de reprendre ce processus.

Merci d’avoir posté cela.

3

Merci pour votre réponse et pour m’avoir orienté vers ces trois index. Je n’avais pas remarqué ce triple exemplaire, car les recommandations n’ont pas été émises simultanément et je les ai appliquées progressivement au fil des semaines.
Il est même assez étrange qu’elles n’apparaissent pas dans les recommandations de DROP. Il semble qu’Azure ait encore du travail à faire :smiley: (et je dois vérifier ces recommandations deux fois).

Cordialement