SQL Assembler
-
blurry333 schrieb:
hustbaer schrieb:
Kann man auch schön sehen wenn man mal ein Batch-File ändert während es ausgeführt wird.)
Wie soll das denn gehen ? Ein File das geöffnet ist , darf man doch gar nicht ändern oder
Es dürfen keine 2 schreibzugriffe gleichzeitig stattfinden. Beim ausführen wird das batch-file aber nur lesend geöffnet, daher kannst es auch ändern. Kommen teilweise aber sehr komische Effekte dabei raus
Grus mdn
-
hustbaer schrieb:
Wobei typischerweise kein Assembler-Code direkt generiert wird.
"Typischerweise" natuerlich nicht, aber Vitesse soll das fuer Postgres per LLVM koennen.
-
Interessant
-
Ja, schaut echt interessant aus. Einige Queries haben die wohl um Faktoren 20 beschleunigt. Scheint aber nicht Open Source zu sein, hätt mir gern mal den Code angeschaut. Wobei ich wahrscheinlich eh nicht dazugekommen wäre...
-
hustbaer schrieb:
Kann man auch schön sehen wenn man mal ein Batch-File ändert während es ausgeführt wird.)
Das hat mich auch schon überrascht.
@blurry: Kommt halt drauf an in welchem Modus man eine Datei öffnet.
-
hustbaer schrieb:
SQL wird praktisch immer kompiliert, der Output des Compilers dann optimiert und der Output des Optimizers dann einer Execution-Engine übergeben.
Wobei typischerweise kein Assembler-Code direkt generiert wird.
Man könnte bei dem was die Execution-Engine macht also vermutlich von "interpretieren" sprechen, wenn man denn wollte.Hier der Vorgang, wie ein SQL Programm normalerweise compiliert wird, und welche Komponenten generiert werden:
http://msdn.microsoft.com/en-us/library/ms713968%28v=vs.85%29.aspx
Dynamic SQL generiert diesen Output während der Programmausführung, embedded SQL wie dargestellt schon während dem Compilieren.
Interessant, dass ich diesen Text bei MS finde. Gibt es von Microsoft Datenbanken, die embedded SQL unterstützen? Ich bin kein MS Programmierer und dachte eigentlich, dass embedded SQL nur von den "grossen" DB Herstellern wie IBM, Oracle, Sybase etc unterstützt wird. Oder liege ich da falsch??
-
Hab bisher auch nicht gesehen, dass MS Embedded SQL kann, aber der SQL Server ist groß. Wenn du schon Sybase erwähnst, ich schätze dass der Sql Server viel größer und weiter verbreitet ist.
-
Mechanics schrieb:
Hab bisher auch nicht gesehen, dass MS Embedded SQL kann, aber der SQL Server ist groß. Wenn du schon Sybase erwähnst, ich schätze dass der Sql Server viel größer und weiter verbreitet ist.
Schon richtig: Sybase erwähnte ich eigentlich nur weil es zu SAP gehört - ich hätte ja auch noch Adabas (Software AG) erwähnen können... die zwei alten Ladys der DB-Geschichte sind eigentlich nur noch eine "Randerscheinung". Aber immerhin unterstützen sie "embedded SQL". Und darum ging es eigentlich in meinem Post.
-
embedded SQL schrieb:
Hier der Vorgang, wie ein SQL Programm normalerweise compiliert wird, und welche Komponenten generiert werden:
http://msdn.microsoft.com/en-us/library/ms713968%28v=vs.85%29.aspx
Dynamic SQL generiert diesen Output während der Programmausführung, embedded SQL wie dargestellt schon während dem Compilieren.
Dynamic SQL ist ja dann hier beschrieben:
http://msdn.microsoft.com/en-us/library/ms713599(v=vs.85).aspx
Schritte 1-3 sind das was ich als "kompilieren" beschrieben habe.
Schritt 4 ist der Optimizer.
Schritt 5 ist die Ausführung des Execution-Plans. Und wie man anhand des Namens (Execution-Plan) sich vielleicht schon denken kann, bedeutet das "run" darin nicht wirklich dass der Execution-Plan direkt von der CPU ausgeführt wird.
Sondern dass er eben einer Execution-Engine übergeben wird, die sich um die Ausführung des Plans kümmert.
Im Prinzip werden Operator-Objekte erzeugt, untereinander verdrahtet, und dann die Ausführung angestossen indem die Execution-Engine Daten durch den so entstandenen Graphen stopft. (Ich vermute mal sie macht das als Pull auf der Ausgabeseite, wäre das einfachste.)Ich würde sagen die Beschreibung von MS entspricht also ziemlich gut dem was ich "skizziert" habe. Findest du nicht?
-
hustbaer schrieb:
Ich würde sagen die Beschreibung von MS entspricht also ziemlich gut dem was ich "skizziert" habe. Findest du nicht?
Natürlich ist das richtig... aber...
Die Eingangsfrage war:
blurry333 schrieb:
Hallo,
blöde Frage. Wird SQL interpretiert oder kompiliert ?
Beim Plan "kann" es sich durchaus um einen executable Code handeln - zumindest bei embedded SQL.
http://dba.fyicenter.com/Interview-Questions/DB2/What_is_a_DBRM_PLAN_.html
In so einem Access Plan wird schliesslich sehr viel vorgehalten, wie etwa gösse der Datenbank/Tabellen, Joins, errechnete Zugriffsstrategie, Berechtigungen bis auf Feldebene usw; und das alles zur Compilezeit.
Bei dynamic SQL dürfte Deine Vermutung stimmen, dass ein Access Plan generiert und einem Interpreter übergeben wird. Das wird ja auch aus dem verlinkten MS Artikel deutlich.Dem TE kann man also antworten: "sowohl interpretiert, als auch compiliert - je nach dem"
Damit sollte die Frage beantwortet sein...
-
nman schrieb:
"Typischerweise" natuerlich nicht, aber Vitesse soll das fuer Postgres per LLVM koennen.
In dem Zusammenhang vielleicht auch ganz witzig:
http://www.slideshare.net/kaigai/gpgpu-accelerates-postgresql
