4. SQL Assembler

SQL Assembler

  • B

    Hallo,

    blöde Frage. Wird SQL interpretiert oder kompiliert ?

    0
  • T

    Jetzt merkt blurry333 immerhin selbst, wie blöd seine Fragen sind. Muss man doch nicht antworten, oder?

    0
  • B

    Wohl interpretiert oder.

    0
  • M

    So blöd find ich die Frage grundsätzlich gar nicht mal. In dem Kontext hier natürlich schon 😉 Aber an sich ist Optimierung von Datenbankabfragen ein spannendes Thema.
    Ich hab mir mal den Sqlite Source angeschaut (auch mal den von MySql aber damals war ich noch ein Schüler, kann mich an nichts mehr erinnern). In Sqlite wird für die Ausführung eine virtuelle Maschine benutzt, fand ich interesant. Also schon auch interpretiert, aber etwas raffinierter, als ich erwartet hätte.
    Das ist aber gar nicht so entscheidend bei der Abfrage. Viel wichtiger ist, einen guten Ausführungsplan zu erstellen und den effizient auszuführen.

    0

  • 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.

    An und für sich ist die Frage "wird kompiliert oder interpretiert" aber in den meisten Fällen doof. Weil sie von der falschen Voraussetzung ausgeht dass es entweder-oder ist. Ist es aber meist eben nicht, meist wird beides gemacht.

    Ausgenommen Sprachen wie C++ wo so-gut-wie nichts interpretiert wird.
    Wobei...
    Bei Sachen wie dynamic_cast könnte man aber auch bei C++ streiten ob hier wirklich nichts interpretiert wird. Bzw. genau so bei dem was bei diversen Dingen wie riesigen switch/case Statements, OpenMP uvm. so abgeht. Da gibt es auch Datenstrukturen die zur Laufzeit von einer Funktion abgearbeitet werden - was man als "interpretieren" bezeichnen könnte.

    (Und natürlich gibt es auch rein interpretierte Sprachen bzw. Implementierungen die rein interpretieren. DOS bzw. Windows Batch Files wären z.B. sowas. Kann man auch schön sehen wenn man mal ein Batch-File ändert während es ausgeführt wird.)

    0
  • B

    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 🙂

    0
  • M

    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

    0
  • N

    hustbaer schrieb:

    Wobei typischerweise kein Assembler-Code direkt generiert wird.

    "Typischerweise" natuerlich nicht, aber Vitesse soll das fuer Postgres per LLVM koennen.

    0

  • Interessant 🙂

    0
  • M

    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...

    0
  • ?

    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.

    0
  • ?

    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??

    0
  • M

    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.

    0
  • ?

    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. 😉

    0

  • 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?

    0
  • ?

    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...

    0
  • N

    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

    0
Anmelden zum Antworten