Das hatte ich ja auch geschrieben.
Würde das nicht dazu führen, dass ein SELECT ohne ORDER BY (seq scan) die Datensätze in der "physischen" Reihenfolge zurückliefert und damit in der Reihenfolge des Index?b) betrifft das nur die physikalische Anordnung der Daten auf der Festplatte. Das hat mit der eigentlichen Ausgabe überhaupt nichts zu tun.
So hatte ich zumindest die (etwas diffuse) Eingangsfrage verstanden.
Nein. Nur unter ganz - mittlerweile muss man "obskur" sagen - Bedingungen.
Die Daten werden ohne ORDER BY in der Reihenfolge ausgegeben, in der sie gelesen werden. Nun ändert aber jedes UPDATE unter Umständen die Position des Eintrags in der Tabelle.
Außerdem gibt es seit einer Weile paralelle Tabellenscans: wenn ein Prozess eine Tabelle liest und ein zweiter will auch etwas aus dieser Tabelle, dann fängt der zweite keineswegs von vorne an. Statt dessen klinkt er sich in den ersten Prozess ein und bekommt die Daten ab dort, wo der erste Prozess gerade ist. Wenn der erste fertig ist, liest der zweite nur noch das Stück (am Anfang), dass ihm noch fehlt.
Die Ausgabe dieser Daten ist dann aber komplett unabhängig von der Reihenfolge auf der Festplatte.
Allgemein bleibt festzuhalten: per Definition ist die Anordnung der Daten bei einem fehlenden ORDER BY nicht deterministisch.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Deswegen meinte ich ja auch, dass das CLUSTER nach jedem Laden der Tabelle (bzw. nach jeder Änderung) neu ausgeführt werden muss.
Ah, das mit den parallelen Scans wusste ich noch nicht. Wie lange gibt es das schon?Außerdem gibt es seit einer Weile paralelle Tabellenscans: wenn ein Prozess eine Tabelle liest und ein zweiter will auch etwas aus dieser Tabelle, dann fängt der zweite keineswegs von vorne an. Statt dessen klinkt er sich in den ersten Prozess ein und bekommt die Daten ab dort, wo der erste Prozess gerade ist. Wenn der erste fertig ist, liest der zweite nur noch das Stück (am Anfang), dass ihm noch fehlt.
Auf einem DB2 "new features" Seminar wurde das dort auch als neues Feature vorgestellt...
Irgendwie haben doch alle die gleichen Ideen
Das CLUSTER würde dann unter Umständen (!) das ORDER BY beschleunigen, oder?Allgemein bleibt festzuhalten: per Definition ist die Anordnung der Daten bei einem fehlenden ORDER BY nicht deterministisch.
Boah ;-)
CLUSTER blockiert die gesamte Tabelle.
Nein, definitiv nicht, keine gute Idee. Um es kurz zu machen: CLUSTER ist hier kein Mittel, dass auch nur ansatzweise zu einer Lösung führt.
8.3, glaube ich.Ah, das mit den parallelen Scans wusste ich noch nicht. Wie lange gibt es das schon?
Nicht wirklich.Das CLUSTER würde dann unter Umständen (!) das ORDER BY beschleunigen, oder?
Es würde dafür sorgen, dass die Daten im Speicher schon (fast oder ganz) richtig sortiert vorliegen, wenn sie im besten Fall passend eingelesen wurden. Sprich: es sind weniger Sortierzyklen notwendig. Aber die sind im Gegensatz zu den I/O-Operationen so billig, dass sich das nicht nennenswert auswirkt.
Außerdem bleibt das Problem der parallelen Scans: die verwerfen dann wieder alles und es muß alles neu sortiert werden.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
8.3. Seit 8.4 nutzt PG z.B. Hasches, um einen UNION zu beschleunigen. Beispiel:
So, was erwartest Du als Resultat? Wird es sortiert sein? Probier es mal mit etwas kleinerem als 8.4, denn in 8.4 passiert dies:Code:test=# create table a (i int); CREATE TABLE test=*# create table b (i int); CREATE TABLE test=*# insert into a values (1); INSERT 0 1 test=*# insert into a values (2); INSERT 0 1 test=*# insert into a values (3); INSERT 0 1 test=*# insert into b values (1); INSERT 0 1 test=*# insert into b values (2); INSERT 0 1 test=*# commit; COMMIT test=# select * from a union select * from b;
Merke: man kann und darf sich nicht auf eine Reihenfolge verlassen, Datenbanken sind Mengenorientiert und diese nicht sortiert.Code:test=# select * from a union select * from b; i --- 3 1 2 (3 rows)
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen