SQL Optimizer - Logische mit Select/Omit

[Fuerchau]

Deswegen sollte man ja an Stelle der LF mit Select/Omit eine View erstellen und den Select darauf loslassen.

Bei meinen Tests (siehe anderer Beitrag) konnte ich nun die SQE dazu bewegen sich einzuschalten.
Ich habe einfach eine QAQQINI in QUSRSYS erstellt und den SQL
update qusrsys/qaqqini
set qqval='*YES'
where qqparm= 'IGNORE_DERIVED_INDEX'
ausgeführt. Und siehe da, ich hatte keinen QueryTimeout mehr, da die pessimistische Zeitschätzung der CQE von ca. 40.000 Sekunden durch die Zeitschätzung der SQE auf 447 Sekunden sank.

Da parallel zu meinem laufenden SQL (ca. 800.000 Sätze) ein 2. Client mit dem gleichen SQL zugriff, sank die reine Queryzeit auf einmal sogar auf 0,2 Sekunden !

Hierzu passt auch die Aussage:
If a derived index exists, have CQE process the query.

Und gerade wegen der CQE steht unser Systemwert QQRYTIMLMT auf *NOMAX, da sonst die meisten AS/400-Queries sonst auf Timeout laufen würden.

Ab V6R1 soll es ja besser werden, da man dann auch berechnete Indices erstellen kann. Wenn dann ein SQL mit Where/Join/Order genau passt, wird dieser wohl auch verwendet werden.

Klar bin ich mit Kenntnis der Anwendung, Ausnutzung der DDS-Möglichkeiten in vielen Fällen mit Native-Access (SETLL/READE/...) schneller, aber SQL-Anwendungen erfordern eh ein anderes Denken und Design.

[B.Hauser]

Und siehe da, ich hatte keinen QueryTimeout mehr, da die pessimistische Zeitschätzung der CQE von ca. 40.000 Sekunden durch die Zeitschätzung der SQE auf 447 Sekunden sank.[/FONT]
Da parallel zu meinem laufenden SQL (ca. 800.000 Sätze) ein 2. Client mit dem gleichen SQL zugriff, sank die reine Queryzeit auf einmal sogar auf 0,2 Sekunden !

Wenn tatsächlich von der SQE ein temporärer Index erstellt wurde, kann dieser genauso wie der Access Plan, der im SQE Plan Cache gespeichert wird, von jedem anderen Job aus verwendet werden, zumindest bis der Access Plan aus dem Plan Cache verschwindet.

Ab V6R1 soll es ja besser werden, da man dann auch berechnete Indices erstellen kann. Wenn dann ein SQL mit Where/Join/Order genau passt, wird dieser wohl auch verwendet werden.

Vorerst können Indices mit Where-Bedingungen nur mit native I/O verwendet werden. Der SQE Query Optimizer kann z.Z. diese Erweiterungen noch nicht nutzen, d.h. es wir genau wie bei SQL-Dateien mit Select/Omit-Anweisungen mit dem kompletten Zugriffsweg gearbeitet.
... aber die Nutzung durch die SQE ist geplant. Die CQE wird diese Indices nie nutzen können.

SELECT auf das PF (Optimizer wählt die LF ohne Omit): ca. 10 Sekunden
SELECT direkt auf die LF mit Omit (Optimizer akzeptiert meinen Vorschlag): < 1 Sekunde.
=> Da hat der "kleine Programmier" wohl den besseren Vorschlag gehabt.

Nein, da war dem Optimizer die DDS-Datei zu komplex bzw. das Rewriting zu aufwändig und die Datei wurde direkt verwendet. Das kommt bei der CQE ab und zu vor.

Was man allerdings bei der CQE/SQE-Geschichte berücksichten sollte. Seit V5R3 können alle Neuerungen nur von der SQE verarbeitet werden.
z.B. Except und Intersect (V5R3), OLAP-Ranking-Funktionen und Rekursive Abfragen (V5R4), RollUp, Cube und Grouping Sets (6.1)

Birgitta