SQL Performance

[BenderD]

Hallo,

frei nach (SQL) Theorie zählt die Ergebnismenge und falls diese gleich ist, sollte das gleich schnell sein. Alles andere sind Dreckeffekte des Analyzers und des Optimizers, die nicht nur mit jedem PTF in die andere Richtung kippen können, sondern auch von Fall zu Fall differieren könnten.

mfg

Dieter Bender

Hallo,

eine kleine Frage.

Was ist schneller

SELECT FELD_A,
(SELECT FELD_B FROM DATEI_B WHERE …)
FROM DATEI_A

Oder

SELECT FELD_A, FELD_B
FROM DATEI_A
LEFT OUTER JOIN DATEI_B

[mariupol1963]

Das stimmt.
Ung. gleiche Antwortzeiten

[Fuerchau]

So ist das nun mal mit den Zeiten.
Es zeigt sich immer wieder, dass Anwendungen mit geringer Satzanzahl entwickelt und getestet werden.
Da waren die Antwortzeiten sogar sehr schnell, obwohl die Tabellen keinerlei Indexe enthielten.

Nachdem die Anwendung nun ein paar Wochen läuft, und inzwischen mehrere 10.000 Datensätze erzeugt wurden, zeigt sich die Schwäche im Design.

Deshalb:
Die Aussagen, was ist schneller oder nicht, hängt auch im Wesentlichen von der Satzanzahl und den verfügbaren Zugriffswegen ab.
Obige Abfrage mit ca. 10.000 Sätzen bei V5R1 brachte ungefähr gleiche Zeiten.
Die selbe Abfrage mit ca. 1.500.000 Sätzen bei V5R3 brachte gravierende Unterschiede. Der beste Zugriff war dort mit dem integrierten skalaren Subselect anstelle der View.

[BenderD]

Hallo,

das ist aber gerade so ein Schmutzeffekt, wie er eigentlich nicht sein sollte. Die alte Query Engine hat offenbar erkannt, dass die View in einen Subselect auflösbar ist und die aktuelle (Beta) Version der viel gepriesenen neuen Query Engine merkt das nicht und berechnet bei Verwendung der View einen suboptimalen Zugriffsplan.

mfg

Dieter Bender

So ist das nun mal mit den Zeiten.
Es zeigt sich immer wieder, dass Anwendungen mit geringer Satzanzahl entwickelt und getestet werden.
Da waren die Antwortzeiten sogar sehr schnell, obwohl die Tabellen keinerlei Indexe enthielten.

Nachdem die Anwendung nun ein paar Wochen läuft, und inzwischen mehrere 10.000 Datensätze erzeugt wurden, zeigt sich die Schwäche im Design.

Deshalb:
Die Aussagen, was ist schneller oder nicht, hängt auch im Wesentlichen von der Satzanzahl und den verfügbaren Zugriffswegen ab.
Obige Abfrage mit ca. 10.000 Sätzen bei V5R1 brachte ungefähr gleiche Zeiten.
Die selbe Abfrage mit ca. 1.500.000 Sätzen bei V5R3 brachte gravierende Unterschiede. Der beste Zugriff war dort mit dem integrierten skalaren Subselect anstelle der View.

[mariupol1963]

Ich habe mit den echten Dateien getestet - ca. 300.000 Sätze.
Die Version mit subselect war ein Tik schneller, aber nicht grossartig.