Dynamisches SQL in einer Stored Procedure

[akretschmer]

Mich würde schon interessieren ob das ein Postgres Alleinstellungsmerkmal ist und was (bzw. wie) das andere DBs handhaben.

Ich vermute mal, Oraggle macht das in irgend einer Art und Weise auch. Ich würde es auch M$SQL zutrauen. Aber genau sagen kann ich es nicht. PostgreSQL hat ein 'Kostenmodell', das recht effektiv ist, Details kann man beim Explain (analyse) dann sehen. Das ist dann schon eine komplett andere Liga als z.B. MySQL.

[fanderlf]

Wie gewünscht habe ich für das Thema mal einen neuen Thread erstellt

Der alte ist hier zu finden: http://entwickler-forum.de/showthrea...%C3%BCbergeben

[defo]

Ich vermute mal, Oraggle macht das in irgend einer Art und Weise auch. Ich würde es auch M$SQL zutrauen. Aber genau sagen kann ich es nicht. PostgreSQL hat ein 'Kostenmodell', das recht effektiv ist, Details kann man beim Explain (analyse) dann sehen. Das ist dann schon eine komplett andere Liga als z.B. MySQL.

Ok, ich hab ja rumgekrittelt, also denn:
Hab mal etwas gelesen und versuche eine kurze, oberflächliche Zusammenfassung für Oracle. (Wie gesagt, ich verlasse mich hauptsächlich auf den CBO ab V10 und muss ihn nicht verstehen. Unter V8 oder 9 mit Rulebased Optimizer oder den ersten CBO Versionen war das anders)
Oracle arbeitet also ebenfalls mit einem Cost Based Optimizer, der u.a. die Selektivität einer Abfrage schätzt und berücksichtigt. Es werden idr automatisch im Hintergrund Statistiken angelegt bzw aktualisiert (wenn man Standardtools zur DB Erstellung verwendet, die Prozesse nicht unterbindet usw usf). Hierbei kann schon erkannt werden, dass die Wertehäufigkeit stark schwankt. In dem Fall werden Histogramme angelegt, die das abbilden.
Die Erstellung von Ausführungsplänen läuft zunächst aber offenbar statisch, also gleiche Query = gleicher Plan (1:1). Hierbei wird aber dynamisch festgestellt, wenn für unterschiedliche Parameter Binds, unterschiedliche Häufigkeiten auftreten. Ich vermute diese Häufigkeiten liegen nicht primär in der Natur der Basistabellen, sondern hängen direkt(er) mit der Abfrage zusammen. Man kann sich leicht vorstellen, dass gewisse Einschränkungen in einer Abfrage direkte Auswirkung auf die Häufigkeitsverteiung der Ergebnisdaten haben.
Wie auch immer, stellt der Optimizer fest, dass eine Abfrage 'bind sensitive' ist, werden anhand von bestehenden (oder zusätzlichen?) Histogrammen weitere Pläne für die Abfrage erstellt und bereitgehalten (1:n) und dann anhand der bind Werte jeweils der "beste" ausgewählt. Die Anführungsstriche habe ich gesetzt, weil auch dieser Prozess wieder komplex ist und ich ihn im Grunde nicht kenne. Abhängig von Indizes, Histogrammen usw. wird entschieden, welcher Pfad verwendet wird. Im Zweifel ist es vielleicht nicht der beste und man ist an dem Punkt, wo man "auf die Fresse fliegt", wenn man sich blind darauf verlässt...

Wenn ich mich richtig erinnere, bestehen gerade im Bereich der Histogramerstellung und Bewertung auch deutliche Unterschiede zwischen Standard und Enterprise Edition. In Enterprise kann man sehr gute Tips von Oracle RDBMS selbst bekommen, wie man Abfragen performanter bekommt. Ich hab aber keine praxisrelevante Erfahrung mit diesen Enterprisefeatures.