Samstag, September 21, 2013

Skalare Subqueries in der WHERE clause

Vor neunundzwanzig Tagen hat Tanel Poder seinen Artikel Scalar Subqueries in Oracle SQL WHERE clauses (and a little bit of Exadata stuff too) veröfffentlicht und ehe der aus meinem reader verschwindet, sollte ich dazu ein paar Notizen machen.
  • eine scalar subquery in der WHERE clause hat die Form: WHERE ... = (select * from ...). Entscheidend ist dabei das Gleichheitszeichen, das diesen Fall von anderen Subqueries unterscheidet.
  • im Plan erscheint der Zugriff eingerückt unter dem Zugriff auf die Daten der main query, wenn in der Transformation eine push subquery operation durchgeführt wird (sichtbar als PUSH_SUBQ in den outline Hints): "So, as subqueries in a WHERE clause exist solely for producing data for filtering the parent query blocks rows, the PUSH_SUBQ means that we push the subquery evaulation deeper in the plan, deeper than the parent query block’s data access path, between the access path itself and data layer, which extracts the data from datablocks of tables and indexes. This should allow us to filter earlier, reducing the row counts in an earlier stage in the plan, thus not having to pass so many of them around in the plan tree, hopefully saving time and resources."
  • wenn man die Transformation mit einem NO_PUSH_SUBQ verbietet, ergibt sich ein Plan, in dem ein Filter step erscheint und darunter der Hauptabellenzugriff und der Zugriff für die Subquery auf einer Einrückungsebene (so wie Filter-Prädikate in der Regel auftreten - oder, vorsichtiger ausgedrückt, wie sie mir normalerweise begegnen), wobei in den Prädikaten die Filter-Query explizit aufgeführt ist.
  • mit PUSH_SUBQ erfolgt die Filterung beim Tabellenzugriff auf die Haupttabelle (die trotzdem komplett gelesen werden muss), während NO_PUSH_SUBQ die Filterung in den Filter step verschiebt. Für gewöhnliche Oracle-Datenbanken ist der Performance-Unterschied nicht allzu groß, aber in einem Exadata-System kann der Smart Scan die Filterung in die storage cells verschieben, was die Laufzeit der Test-Query dramatisch reduziert.
Klingt mal wieder, als wäre Exadata ein spannendes Thema...

Keine Kommentare:

Kommentar veröffentlichen