diff --git a/_data/posts/amelioration-d-index-comment-on-a-mis-le-doigt-sur-le-probleme.md b/_data/posts/amelioration-d-index-comment-on-a-mis-le-doigt-sur-le-probleme.md index f7a8bc6..9b1546b 100644 --- a/_data/posts/amelioration-d-index-comment-on-a-mis-le-doigt-sur-le-probleme.md +++ b/_data/posts/amelioration-d-index-comment-on-a-mis-le-doigt-sur-le-probleme.md @@ -74,6 +74,7 @@ Elle permet de jouer des requêtes en amont de notre `SELECT` et de stocker le r C'est pratique pour limiter les jointures et optimiser au maximum les index définis sur les tables. +```sql WITH temp_table_1 AS ( SELECT id as table_1_id @@ -114,6 +115,7 @@ C'est pratique pour limiter les jointures et optimiser au maximum les index déf OR EXISTS(SELECT table_1_id FROM temp_table_3 WHERE table_1_id = t.id) ) ORDER BY t.created_at DESC, t.id ASC LIMIT 20; +``` L'utilisation de la commande `WITH` nous a permis d'avoir de bons résultats. Lors de nos tests sur un replica de nos tables, pour la même requête réécrite, nous passions d'environ 45 secondes à seulement 2 secondes ! @@ -133,21 +135,26 @@ A l'aide des analyses précédentes et en jouant certaines parties indépendamme Par exemple la requête ci-dessous, mettait en moyenne moins d'une seconde pour avoir un résultat : +```sql SELECT id FROM "table_2" WHERE name ILIKE '%%'; +``` Idem, pour la requête ci-dessous : +```sql SELECT id FROM "table_2" WHERE first_name ILIKE '%%' OR last_name ILIKE '%%' OR phone ILIKE '%%' OR email ILIKE '%%'; +``` Par contre, ces deux requêtes ensemble avec une jointure et des conditions `WHERE ... OR ...` comme ci-dessous dedans faisait exploser le temps à plus de 60 secondes. +```sql SELECT t.* FROM "table_1" s WHERE t.workspace = '' @@ -187,6 +194,7 @@ Par contre, ces deux requêtes ensemble avec une jointure et des conditions `WHE ) ) ORDER BY t.created_at DESC, t.id ASC LIMIT 20; +``` Du coup, on s'est dit, pourquoi ne pas tout mettre à plat ?