C'est bien ce que je pensais : chacune des sous-requêtes est exécutée 52049079 fois (50 000 000)! C'est bien un accès par index, mais 50 millions de fois, c'est long quand même. (c'est les 2 "Bitmap Index Scan")
Le 'Or' est également fait plus de 50 mullions de fois, et est un peu plus long.
C'est cela qui est le plus coûteux.
En gros, le moteur prend chaque ligne de la table user et sélectionne les lignes de email telle que mixiuser.id = target_id, celles telle que mixiuser.id = target_id, puis vérifie si la condition est vérifiée.
Si tu regardes bien, les requêtes dans email + le 'or', cela prend 0.007 millisecondes.
Multiplié par 52049079 , c'est 364343,553 (environ 6 minutes)
Ajoutes 211619.619 pour le parcours séquentiel de la table (3,5 minutes environ)…
Alors que si tu réécris la requête avec une jointure je suppose qu'il utilise un moyen bien plus efficace (pas un nested loop évidemment, un merge ou un sort join).
Il est possible aussi que l'optimiseur "réécrive" la requête s'il n'y a qu'un seul exists, mais n'y arrive pas avec les 2 et le or, vu la grande différence de temps de réponse.
Je me demande pourquoi cet ORM fait les requêtes comme cela, c'est généralement beaucoup moins bon, en tout cas sous Postgres ou Oracle.
[^] # Re: explain
Posté par Flo . En réponse au message performances de JOIN / EXISTS sur postgres. Évalué à 2.
C'est bien ce que je pensais : chacune des sous-requêtes est exécutée 52049079 fois (50 000 000)! C'est bien un accès par index, mais 50 millions de fois, c'est long quand même. (c'est les 2 "Bitmap Index Scan")
Le 'Or' est également fait plus de 50 mullions de fois, et est un peu plus long.
C'est cela qui est le plus coûteux.
En gros, le moteur prend chaque ligne de la table user et sélectionne les lignes de email telle que mixiuser.id = target_id, celles telle que mixiuser.id = target_id, puis vérifie si la condition est vérifiée.
Si tu regardes bien, les requêtes dans email + le 'or', cela prend 0.007 millisecondes.
Multiplié par 52049079 , c'est 364343,553 (environ 6 minutes)
Ajoutes 211619.619 pour le parcours séquentiel de la table (3,5 minutes environ)…
Alors que si tu réécris la requête avec une jointure je suppose qu'il utilise un moyen bien plus efficace (pas un nested loop évidemment, un merge ou un sort join).
Il est possible aussi que l'optimiseur "réécrive" la requête s'il n'y a qu'un seul exists, mais n'y arrive pas avec les 2 et le or, vu la grande différence de temps de réponse.
Je me demande pourquoi cet ORM fait les requêtes comme cela, c'est généralement beaucoup moins bon, en tout cas sous Postgres ou Oracle.