Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 15 von 15

Thema: Sortierung von referenzierten Primärschlüsseln

  1. #11
    castorp ist offline Erfahrener Benutzer
    Registriert seit
    27.06.2009
    Beiträge
    493

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    a) ist diese Sortierung nicht permanent sondern verflüchtigt sich bei nachfolgenden Änderungen wieder
    Das hatte ich ja auch geschrieben.

    b) betrifft das nur die physikalische Anordnung der Daten auf der Festplatte. Das hat mit der eigentlichen Ausgabe überhaupt nichts zu tun.
    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?
    So hatte ich zumindest die (etwas diffuse) Eingangsfrage verstanden.

  2. #12
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Zitat Zitat von castorp Beitrag anzeigen
    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?
    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

  3. #13
    castorp ist offline Erfahrener Benutzer
    Registriert seit
    27.06.2009
    Beiträge
    493

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    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.
    Deswegen meinte ich ja auch, dass das CLUSTER nach jedem Laden der Tabelle (bzw. nach jeder Änderung) neu ausgeführt werden muss.

    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.
    Ah, das mit den parallelen Scans wusste ich noch nicht. Wie lange gibt es das schon?

    Auf einem DB2 "new features" Seminar wurde das dort auch als neues Feature vorgestellt...
    Irgendwie haben doch alle die gleichen Ideen

    Allgemein bleibt festzuhalten: per Definition ist die Anordnung der Daten bei einem fehlenden ORDER BY nicht deterministisch.
    Das CLUSTER würde dann unter Umständen (!) das ORDER BY beschleunigen, oder?

  4. #14
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Zitat Zitat von castorp Beitrag anzeigen
    Deswegen meinte ich ja auch, dass das CLUSTER nach jedem Laden der Tabelle (bzw. nach jeder Änderung) neu ausgeführt werden muss.
    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.


    Ah, das mit den parallelen Scans wusste ich noch nicht. Wie lange gibt es das schon?
    8.3, glaube ich.


    Das CLUSTER würde dann unter Umständen (!) das ORDER BY beschleunigen, oder?
    Nicht wirklich.
    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

  5. #15
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Nähe Dresden
    Beiträge
    5.337

    Standard

    Zitat Zitat von castorp Beitrag anzeigen

    Ah, das mit den parallelen Scans wusste ich noch nicht. Wie lange gibt es das schon?
    8.3. Seit 8.4 nutzt PG z.B. Hasches, um einen UNION zu beschleunigen. Beispiel:

    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;
    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=# select * from a union select * from b;
     i
    ---
     3
     1
     2
    (3 rows)
    Merke: man kann und darf sich nicht auf eine Reihenfolge verlassen, Datenbanken sind Mengenorientiert und diese nicht sortiert.

    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

Seite 2 von 2 ErsteErste 12

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum