À la grosse louche, j'imagine que le parser de requête optimise la requête en groupant le premier select et la clause à gauche du OR pour ne faire qu'une seule jointure. Ensuite, pour chaque ligne restante, si le résultat est false, alors on va voir s'il y a moyen de repêcher la ligne si la clause "exists" à droite du OR est true. Dans le cas général où les requêtes sont très différentes à gauche et à droite du OR, ça doit procurer un boost de performances. Dans le cas particulier ou, en fait, les deux clauses fonctionnent sur les même données, visiblement ça induit une baisse de perf assez phénoménale.
Bon, tu avais peut être déja eu le même raisonnement, et j'ai pas un avis d'expert, mais si j'étais un sgbdr (le rêve), bin je ferais ça.
# Evaluation paresseuse
Posté par fredoche . En réponse au message performances de JOIN / EXISTS sur postgres. Évalué à 1.
À la grosse louche, j'imagine que le parser de requête optimise la requête en groupant le premier select et la clause à gauche du OR pour ne faire qu'une seule jointure. Ensuite, pour chaque ligne restante, si le résultat est false, alors on va voir s'il y a moyen de repêcher la ligne si la clause "exists" à droite du OR est true. Dans le cas général où les requêtes sont très différentes à gauche et à droite du OR, ça doit procurer un boost de performances. Dans le cas particulier ou, en fait, les deux clauses fonctionnent sur les même données, visiblement ça induit une baisse de perf assez phénoménale.
Bon, tu avais peut être déja eu le même raisonnement, et j'ai pas un avis d'expert, mais si j'étais un sgbdr (le rêve), bin je ferais ça.