Timestamp und PostgreSQL 8.1

Ich habe mal die Frage, wenn ich aus einem Timestamp z.B. die Woche oder den Monat in einer SQL-Abfrage extrahiere, ob PG dann einen Index benutzt und wenn, wie muss der gestaltet sein?

Ich arbeite hier an einer Produktionsdatenbank, die massiv mit einem Timestamp arbeitet, der jedoch noch konvertiert werden muss, da die 3 Schicht über 24:00 hinausgeht, aber zum Vortag gerechnet wird. Ich mache das per Trigger, in dem ich ein 2. Timestamp-Feld mit in den Datensatz lege. Dazu wird dann noch ein Feld Schichtnummer mit angelegt, aber auch Ergebnisse in Abhängigkeit von Schichten zu bekommen. Dieses Vorgehen führt zu vielen Indexen und das kostet Zeit bei der Auswertung. Ich würde lieber allein mit der konvertierten Zeit (Timestamp - X Stunden) arbeiten. Eine ähnlich Strategi würde ich mit der Wochenummer fahren, die ebenfalls als Feld mit gespeichert wird, um die schnelle Auswertung in Bezug zur Woche zu haben, da bisher PG8.0 bei solchen Funktionen keinen Index nutzte.

Kennt sich da jemand aus. Bisher fahre ich nur PG 8.0 und würde das wie angesprochen gerne anders machen.

Hallo drfunfrock,

PostgreSQL erzeugt von sich selbst aus keinen einzigen Index. Die muss Du schon mit CREATE INDEX selbst anlegen. Es gibt da viele Möglichkeiten, wie man einen Index gestaltet kann. Die Indizierung von Feldern in einer Tabelle erhöht grundsätzlich die Geschwindigkeit. Welchen Index Deine Anweisung anwendet, kannst Du mittels EXPLAIN feststellen.

Ein Schicht hat grundsätzlich 2 TimeStamp-Felder: Anfang und Ende. Über die Differenz, Ende - Anfang, kann daher die Brutto-Arbeitszeit bestimmt werden.

Unter “worst case” betrachtet, ist Anfang und Ende wegen der Randbedingung (Verspätung, Unfall, Kranheit während der Arbeitszeit, etc) nicht bestimmbar. Die Schichtzuordnung ist nur dadurch bestimmbar, indem man feststellt, in welchem Zeitfenster die Anfangszeit liegt.

Wenn nicht zwingend notwendig, würde ich auf einen Trigger bei der Eingabe verzichten. Die Schichtzuordung kann auch bei der ersten Auswertung erfolgen. Das Feld setzt man daher defaultmäßig auf den Wert NULL.

Wenn ein bestimmter Wert (z. Woche) das Haupkriterium bei der Selektierung ist, sollte hierfür ein eigenes Feld angelegt werden. Dieses sollte zudem auch noch indiziert werden.

Eine Verbessung der Leistung kann sich auch ergeben, indem man die Rohdaten in einer Tabelle sammelt und diese erst nach der Auswertung in die eigentliche Tabelle verschiebt.


Dieses Vorgehen führt zu vielen Indexen und das kostet Zeit bei der Auswertung.

Schon mal die Geschichte der Entwicklung von Datenbanken gelesen? Sehr interessant! Übrigens, die Indizierung von Feldern war das erste, was man zur Steigerung er Leistung eingeführt hat. Aber das widerspricht ja Deinen Erfahrungen. Nur bei anderen funktioniert es. Was nun?



mfg

fristo

Ich habe mich missverständlich ausgedrückt:

Die Indexes sind natürlich vorhanden. Dann erzeugt die Anlage die Daten (Vereinfacht):

Timestamp, Attribut und Attributwert

und zwar nicht durch den Operator, sondern durch die SPS (jede Sekunde so 10Stk. Da bisher PG aber bei Funktionen wie Max und Min den Index nicht nutzen konnte, ergänzte ich den Datensatz mittels Trigger (Extrationen von Zeitkomponenten) durch

korrigierte Zeit (Tagesanfang mit erster Schicht 7:00), Woche.

Denn der Index wurde vom Optimizer nicht genutzt, wenn ich eine Funtion in der Abfrage nutzte, die z.B. die Wochenzahl extrahierte und eine Bedg. an diese knüpfte, wie:

extract(‘week’ FROM logcdate) = 5

Deswegen die Frage nach der der PG-Version 8.1, ob diese in diesem Fall einen Index nutzt?

Hallo drfunfrock,

Deine Frage kann man so nicht beantworten, da Du Dich hier nur Fragmente einer SQL-Anweisung beschreibst.

Indexe werden vom SELECT benutzt um die Anzahl der Datensätze einzuschränken. Dabei muss der Index den einschränkenden Bedingungen für den SELECT unterstützen.

Funktionen, WIE Du sie hier aufgeführt hast, Min, Max oder Extract, werden über bzw. für jeden selektierten Datensatz ausgeführt. Der Index spielt daher nur bei der Auswahl der Datensätze eine Rolle.


Um mal zu Deinem Beispiel zu kommen

extract(‘week’ FROM logcdate) = 5

Eine zusätzliche, indizierte Spalte “week” würde die Anweisung

SELECT          *
FROM            logcdate
WHERE           week = 5

schon wesentlich schneller ausführen, da hier nur für jede Spalte eine ‘=’-Funktion und nicht zusätzlich die ‘extract’-Funktion ausgeführt werdern müste.



mfg

fristo