Performance sqlrpgle / strsql

[BenderD]

@D*B
Nee, nix Stored Procedure
Das Sql wird doch vom Compiler umgewandelt in einen call.
Und dieser call, der den 1. Fetch (fetch first from cursor01 into :f1, F2, ...)
dauert schon endlos.

Robi

... aus dem interaktiven SQL erfolgt hier auch nicht viel was anderes. Die lange Dauer für den ersten fetch könnte eben gerade auf einen full table scan hindeuten.
Die join order könnte man über die QAQQINI forcieren, würde ich aber normal nicht empfehlen. In jedem Fall würde ich einen order by machen, falls keiner da ist, das kann den Query Optimizer auch in eine Richtung schieben.

D*B

[B.Hauser]

Es gibt schon einen Unterschied zwischen STRSQL und statischem embedded SQL und zwar ist es das Optimierungsziel. Alle dynamsichen SQL-Statements (damit auch Abfragen aus STRSQL) werden per Default mit dem Optimierungsziel *FIRSTIO (der erste Datenblock muss so schnell wie möglich zurückgebracht werden). Statisches SQL wird per default mit Optimierungsziel *ALLIO optimiert, d.h. das komplette Ergenis muss so schnell wie möglich zurückgebracht werden.

Normalerweise hat das Optimierungsziel wenig Einfluss, kann aber genau in dem Moment wo sich der Optimizer zwischen Table Scan und halb-optimalem Index-Zugriff entscheidend sein.
Bei Dir ist genau diese Situation eingetreten.

Das Optimizerungsziel kann über die OPTIMIZE FOR X ROW-Anweisung beeinflusst weden.
Wird X durch eine kleine Zahl ersetzt, wird Optimierungsziel *FIRSTIO verwendet. Wird X durch eine sehr große Zahl oder ALL ersetzt wird Optimierungziel *ALLIO verwendet.

Birgitta

[Fuerchau]

Wobei ich diesem "Optimize for" nicht soi ganz traue, da ich trotz vieler Versuche selten einen Effekt erzielen konnte.

[Robi]

@D*B
alle fetch sind langsam, der erste ist definitiv nicht der 'schuldige'

@Baldur und Birgitta
also der optimize ist ja schnell eingebaut gewesen
for 9 rows keine Verbesserung
for 1 rows keine Verbesserung
das ist echt krank!

Ich glaube das ist eher langsamer geworden!

[Robi]

Warscheinliche Ursache:
DECLARE C1 DYNAMIC SCROLL CURSOR FOR SE_FLD1

statt
DECLARE C1 SCROLL CURSOR FOR SE_FLD1

jetzt ist die performance ok

Danke Euch allen

Robi

[BenderD]

ersteres erlaubt keine temporäre Kopie, was den Geschwindigkeitsunterschied erklärt.

D*B

[Fuerchau]

Auch stellt sich die Frage, warum einen Scroll-Cursor.
Das kann man doch mittels Subfile besser lösen.

Aber schön, dass du es doch selber gefunden hast.
Im STRSQL->F13 gibts hierzu die EInstellung "Datenaktualisierung" und "Datenkopie".
Schau dir dann mal deine Abfrage mit *ALWAYS an...