Új hozzászólás Aktív témák

• sztanozs veterán

  #4149

  #4148 bambano

  2019-05-15 14:24:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #4148 bambano

  #4148 bambano

  megnéztem rendesebben a kérdést, és nem látom értelmét bemásolni az eredményt.
  az explain és az explain analyze egymáshoz képest fordított eredményt hoz. az explain szerint a not in 4x gyorsabb, az explain analyze szerint meg az exists gyorsabb.

  ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz, ami a fő selectben van. egyébként pedig a postgresql-nél ez a probléma régebben felmerült, úgy látom, hogy a query plannere fel van rá készítve és jó eredményt hoz.

  ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz
  Elméletileg pont fordítva. A NOT IN-hez kell iterálni, az NOT EXISTS anti-joinra konvertálható (csak ebben a formában szebb).

  Analyse jól írja, mert tényleg pont fordítva van, mert az exists és a left join + null is anti-joinra van optimalizálva, a not in pedig hashed subplan (mert az IN értéket és null-t is visszaadhat, ezért kétszer fut az iteráció - ki elemszámnál ez nem probléma, de nagy elemszámnál már lesz különbség, ráadásul a subplan miatt cache problémák lehetnek).

  EXPLAIN ANALYZE
  It is possible to check the accuracy of the planner's estimates by using EXPLAIN's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows.

Új hozzászólás Aktív témák