View Full Version : SQL Performance bei Aggregatfunktion
dschroeder
07-03-13, 14:37
Das ist bei uns sicher der Fall. Das eigentliche Performanceproblem wird aber durch große Schleifen ausgelöst, in denen immer wieder in die Datei geschrieben wird. Ich hoffe, dass da nicht immer wieder ein Datenpfad neu geöffnet werden muss.
Dieter
andreaspr@aon.at
07-03-13, 14:43
... und damit kommen wir wieder zum Stichwort Performance Monitor ;)
Dort siehst du dann sogar in der Zusammenfassung ganz am Anfang welche und wieviele OPENs gemacht wurden.
lg Andreas
Die Aggregat-Funktion geht natürlich auch über den Index und macht auch in diesem Fall einen Index-Only-Access.
In wie weit die MAX-Funktion eben einen absteigenden Index verwendet (optimiert ist) kann ich nicht sagen.
Allerdings ist MAX eben so definiert, dass in einer Liste der größte Wert ermittelt werden soll.
Und das genau tut eben SQL (siehe Visual Explain).
Wie gesagt, mit einem explziten Zugriff per Order By auf 1 Satz sollte es auch funktionieren.
RPG ist dann langsamer, da immer auch auf die Datenbereiche zugegriffen wird, während SQL eben nur den Index-Teil verwenden kann.
dschroeder
07-03-13, 14:59
Ach, jetzt habe ich verstanden, weshalb du einen absteigenden Index haben wolltest: Du meinst, auf max() verzichten und stattdessen einen cursor öffnen und den ersten Satz lesen. Das könnte man wirklich nochmal versuchen!
Dieter
dschroeder
07-03-13, 15:04
Mit dem Performance Monitor tue ich mich immer wieder etwas schwer. Wir benutzen das Tool so selten. Deshalb ist es immer wieder etwas aufwendig, da einzusteigen.
Aber wahrscheinlich muss ich das wohl machen.
Dieter
... und damit kommen wir wieder zum Stichwort Performance Monitor ;)
Dort siehst du dann sogar in der Zusammenfassung ganz am Anfang welche und wieviele OPENs gemacht wurden.
lg Andreas
RPG ist dann langsamer, da immer auch auf die Datenbereiche zugegriffen wird, während SQL eben nur den Index-Teil verwenden kann.
Dann nimm besser SQL. ;)
Die Aggregat-Funktion geht natürlich auch über den Index und macht auch in diesem Fall einen Index-Only-Access.
In wie weit die MAX-Funktion eben einen absteigenden Index verwendet (optimiert ist) kann ich nicht sagen.
Allerdings ist MAX eben so definiert, dass in einer Liste der größte Wert ermittelt werden soll.
Und das genau tut eben SQL (siehe Visual Explain).
Wie gesagt, mit einem explziten Zugriff per Order By auf 1 Satz sollte es auch funktionieren.
RPG ist dann langsamer, da immer auch auf die Datenbereiche zugegriffen wird, während SQL eben nur den Index-Teil verwenden kann.
... bringt nix, lässt sich leicht mit
select nummer from...
where ...
order by...
fetch first row only
verifizieren. Zum test kann man sich den zusätzlichen Index sparen und die kleinste holen.
ISAM (setll usw.) ist hier signifikant schneller, der Index only access spart hier eh' nur Hauptspeicher.
Wenn da nur ein Prozess reinschreibt, kann man da mit caching im zentralen getter einiges rausholen, da muss man sich allerdings noch ein paar Gedanken über konkurrierende updates machen...
D*B
Nach einem Test nimmt SQL bei der Funktion MAX den absteigenden Index und hat mir aus einer Datei mit ca. 37 Mio Sätzen und einem 3-teiligen Schlüssel aus 2700 Sätzen quasi blitzartig den größten Wert ermittelt !
Nach einem Test nimmt SQL bei der Funktion MAX den absteigenden Index und hat mir aus einer Datei mit ca. 37 Mio Sätzen und einem 3-teiligen Schlüssel aus 2700 Sätzen quasi blitzartig den größten Wert ermittelt !
... was man so blitzartig nennt - ich habe das auch auf einer großen Installation mit ein paar hundert Millionen records gebenchmarked und der Zugriffsplan weist zwar index only access aus, aber die Büchse beschäftigt sich blitzartig mit einigen Tausend Datensätzen - ISAM (setlll und Co) spielt da trotzdem in einer anderen Liga.
Wobei: für mich ist das Design crude, der getter kann sich das pro Key in eine Keytable reinmalen und schon geht das unabhängig von der Zugriffsmethode flott und effektiv - und ist auch weniger anfällig und funzt auch mit Commit.
D*B