Bonjour,

Je n'arrive pas à expliquer une importante différence de performance sur une requête simple, en fonction de l'évolution du seul paramètre "account_id" :

SELECT * FROM listings_5
WHERE account_id = 981
ORDER BY state ASC
LIMIT 50 OFFSET 0

"listings_5" est une table enfant de "listings". Le découpage est effectuée en fonction de la valeur d'un champ "store_id".
Les colonnes "account_id", "state" et "store_id" sont indexées.

Lorsque je lance la requête ci-dessus directement sur la table "listings_5" pour account_id = 981, j'obtiens ceci :
(la table contient 154 461 enregistrements pour le compte 981)

Limit  (cost=0.00..684.02 rows=50 width=1452) (actual time=238.055..2027.142 rows=50 loops=1)
  ->  Index Scan using listings_5_state_idx on listings_5  (cost=0.00..1960460.66 rows=143305 width=1452) (actual time=238.053..2027.093 rows=50 loops=1)
        Filter: (account_id = 981)
Total runtime: 2027.265 ms

Pour account_id = 1699 :
(alors que la table ne contient aucun enregistrement pour le compte 1699)

Limit  (cost=0.00..17029.71 rows=50 width=1452) (actual time=95497.761..95497.761 rows=0 loops=1)
  ->  Index Scan using listings_5_state_idx on listings_5  (cost=0.00..1960460.66 rows=5756 width=1452) (actual time=95497.759..95497.759 rows=0 loops=1)
        Filter: (account_id = 1699)
Total runtime: 95497.856 ms

En exécutant ces requêtes l'une après l'autre à plusieurs reprises, j'obtiens à peu près le même résultat.

J'ai effectué un VACUUM ANALYSE sur toutes les tables, j'ai redémarré la base, j'ai réindexé les tables listings, sans succès.
De plus je ne constate pas cette différence sur ma seconde machine de test, même matériel, même config, mais qui contient une version plus récente de ma base de prod (donc plus lourde).

Autres précisions :
- Si j'effectue la même requête sur la table mère, en précisant store_id = 5, la tendance s'inverse... (instantané pour 1699, quelques secondes pour 981)
- Si je supprime le critère de tri, le temps de réponse est "normal"...
- Si j'ajoute un critère de tri final (listing_id, la clé primaire), le temps de réponse est "normal" également... (instantané pour 1699, quelques secondes pour 981) :

SELECT * FROM listings_5
WHERE account_id = 1699
ORDER BY state ASC, listing_id
LIMIT 50 OFFSET 0

-------

Limit  (cost=19855.16..19855.28 rows=50 width=1468) (actual time=0.015..0.015 rows=0 loops=1)
  ->  Sort  (cost=19855.16..19869.84 rows=5872 width=1468) (actual time=0.014..0.014 rows=0 loops=1)
        Sort Key: state, listing_id
        Sort Method:  quicksort  Memory: 17kB
        ->  Index Scan using listings_ebay_account_idx on listings_ebay  (cost=0.00..19660.09 rows=5872 width=1468) (actual time=0.008..0.008 rows=0 loops=1)
              Index Cond: (account_id = 1699)
Total runtime: 0.149 ms

Bref, je vous avoue que je suis un peu perdu. Je ne sais pas quelle démarche effectuer pour traquer le problème.
C'est pourquoi je fais appel à vous...

Merci pour tout élément de réponse !

Bonjour,

J'ai 2 tables, "commande" et "produit". Une commande est liée à 1..n produit(s).
J'ai ajouté une colonne "prix" à "commande", somme des prix des produits associés, calculé automatiquement par trigger.

Je souhaite maintenant que ce champ "prix" soit en lecture seule. J'ai donc ajouté un trigger sur la table "commande" pour empêcher tout UPDATE.
Le problème est que je souhaiterais quand même laisser passer l'UPDATE provenant du trigger sur la table "produit"...

Est-il possible de détecter l'origine d'un UPDATE et d'agir en conséquence ?

Merci,
Julien