Abfrage beschleunigen

Hallo,

ich habe verschiedene Daten, die normalisiert in veschiedenen Tabellen vorliegen. Die Einzeltabellen bestehen aber nicht nur aus aus 1-2 Spalten, sondern auch noch teilweise bis zu 10.

So, jetzt sollte eine Abfrage (und daraus eine View) erzeugt werden, die verschiedene Werte aus den verschiedenen Tabellen integriert.

Nun habe ich dann zig Konstrukte, wie

SELECT A.a, A.b, B.a, B.b, B.c, …
FROM A INNER JOIN B ON A.a = B.a INNER JOIN C ON …

Man kann sich leicht vorstellen, dass das lange dauert.

Kann man das denn irgendwie noch optimieren? Ich kann mir vorstellen, dass mit steigender Spaltenzahl in den Einzel-Tabellen auch ein JOIN länger dauert, oder ist das nicht richtig? Ich weiss, dass JOINs die zeitintensivsten Operationen sind, aber irgendwie muss ich ja jetzt die ganzen Tabellen wieder mit den entsprechenden Werten zusammenbringen.

Also was ist hier zu tun? Bleibt nur noch, die Zeit, die so eine Abfrage benötigt, abzuwarten, oder bekommt man das mit einfachen Grundregeln schon gut optimiert? Würde es was bringen, wenn ich mir noch weitere “Zwischentabellen” erzeuge, die nur wenige Spalten haben und diese dann für die Endgültige View JOINe?

keine angst - das ist noch lange keine bedenkliche groeßenordnung

Da kann man was machen

theoretisch kann man sagen, dass die performance der joins mit der anzahl der spalten nichts zu tun hat … joins betreffen indizes … du musst auf die felder, die in join-bedingung (hinter on) verwendet werden geeignete indizes erzeugen. … das ist wie im richtigen leben - wenn du ein geordnetes verzeichnis (index) von deiner papierwueste hast, dann findest vieles alles schneller

du schaust dir jetzt also die postgres-dokumentation zum thema CREATE INDEX an …

um zu gucken was der server macht schreibst du ein EXPLAIN ANALYSE vor deiner query …

das ist fuer einen einsteiger ein leicht komplexes thema … man arbeitet sich aber recht schnell ein …

Ein Index wird nicht zwangsweise genutzt. Ob der verwendet wird, hängt von vielen Faktoren ab.

Beim Optimieren würde ich erst mal bei der Datenbank selbst anfangen: was hast du da schon konfiguriert, auf was für Hardware läuft das ect.

er braucht nen grundkurs - machs doch nich gleich so kompliziet :p

Hhm, ja indizes sind ne gute Idee. Nur hab ich da aus verschiedenen Tabellen wieder Views generiert.

Ich nehme an, dass es bei solch einer View eines extra Indexes bedarf, was aber auf Views nicht geht.


BTW, wenn ich eine neue View generiere und es ändert sich was an den physischen Tabellen, wird doch die View gleich upgedatet, oder? Also sprich, ne View ist immer aktuell bzgl. der physischen Tabellen-Daten?

Views sind bloß ein Alias für eine bestimmte Abfrage.
Der Parser tut als ersten Schritt den View gegen die eigentliche Abfrage auf den richtigen Tabellen ersetzen und dort werden dann die vorhandenen Indicies verwendet.



BTW, wenn ich eine neue View generiere und es ändert sich was an den physischen Tabellen, wird doch die View gleich upgedatet, oder? Also sprich, ne View ist immer aktuell bzgl. der physischen Tabellen-Daten?

In PostgreSQL? Nein.
Hast du es probiert?


Ach, und wo bleiben die Beispieldaten?

OMFG.

Nur hab ich da aus verschiedenen Tabellen wieder Views generiert.

Ich nehme an, dass es bei solch einer View eines extra Indexes bedarf, was aber auf Views nicht geht.

Siehe ads. Ein VIEW ist keine physische Tabelle. Abfragen gegen eine VIEW werden intern durch die Definition des VIEWs ersetzt, damit wird die Abfrage letztendlich gegen die eigentlichen Tabellen ausgeführt. Dort vorhandene Indexe werden, falls sinnvoll, natürlich verwendet.

BTW, wenn ich eine neue View generiere und es ändert sich was an den physischen Tabellen, wird doch die View gleich upgedatet, oder? Also sprich, ne View ist immer aktuell bzgl. der physischen Tabellen-Daten?

Wenn Du das, was ads und ich weiter oben geschrieben haben, sinnentnehmend gelesen hast, beantwortet sich Dir diese Frage von selbst.


Andreas

Okay, ich halte mal fest:

  1. Indizes auf den Tabellen werden auch bei Views genutzt
  2. Views sind nur ein Alias, für die Abfrage auf den tatsächlichen Tabellen

=> Daraus folgere ich dann, dass View auch immer aktuell sind. Wenn ich also ein SELECT * FROM myview ausführe, bekomme ich auch nach dem Erstellen der View und einem anschließenden INSERT in die referenzierte Tabelle auch diese neuen Daten angezeigt?

Richtig kombiniert.