Druckbare Version
Um die Daten geordnet abzulegen, habe ich einen Index erstellt:
CREATE UNIQUE INDEX data_index ON data (foo, foo1);
aber Abfragen mit
SELECT * FROM data ORDER BY foo,foo1 LIMIT %d OFFSET %d
zeigen, dass die Daten nicht nach foo,foo1 geordnet sind, weil diese Abfragen zunehmend langsamer werden, trotz heftiger Platten-Aktivität von PostgreSQL.
Wie bekommt man denn die Daten nach foo,foo1 geordnet? :confused:
Indizes sortieren deine Datenbank-Tabelle nicht, sie legen nur einen Zeiger auf die einzelnen Datensätze.
Bei MaxDB gibt es einen Befehl "REORGANIZE", die die Tabelle sinnvoll anordnet (was bei großen Tabellen auch ganz schön dauert). Vielleicht gibt es sowas bei PostGres aus?
Aha, danke, aber ein INDEX ohne die Daten danach anzuordnen ist doch IMHO Snakeoil, weil's fast nichts bringt, denn auch damit dauert das Ausgeben der Daten in der Index-Reihenfolge schon bei wenigen Millionen Datensätzen viele Tage lang!
Wozu soll denn INDEX ohne REORGANIZE gut sein? :confused:
Und wie heißt REORGANIZE unter PostgreSQL? :confused:
Ein Index speichert nur, wo was steht. Es muss also nicht danach gescannt werden. Eine Sortierung ist dafür nicht erforderlich, würde auch wenig bringen.
Nehmen wir mal an, du hast eine Tabelle mit 100000 Einträgen. Suchst Du nach einem Bestimmten Eintrag, muss die Tabelle gescannt werden. Egal, ob sie geordnet ist, oder nicht, wird so lange gescannt, bis gefunden/oder nicht gefunden wurde. Ist das betreffende Feld nicht unique, muss die ganze Tabelle durchlaufen werden. Der Index besagt, wo die Sachen stehen und es muss nur der Index, nicht aber die ganze Tabelle durchlaufen werden. Das Picken aus der Tabelle geschieht dann gezielt.
Bei einzelnen Zugriffen kann man einen index ohne reorganize noch verwenden, aber spätestens wenn man viele Zugriffe blockweise hat, braucht man reorganize.
Ansonsten werden die Daten zwar im Prinzip relativ schnell gefunden, aber weil der Schreib-Lese-Kopf der HD die Daten von verschiedenen Bereichen der HD suchen muß, ist das sehr langsam; die Daten kommen sozusgen nur tröpfchenweise.
Ich bin zwar noch jung und kann warten, aber wenn sowas einfaches wie das nach dem Index geordnete ausgeben der Daten einige Jahre dauert, ist es unbrauchbar.
Irgendwelche Vorschläge? :confused:
aja, und was mach ich bitte bei 2 indizes auf ein und dieselbe tabelle?Zitat:
Zitat von nobody0
ein index enthält per definitionem nur verweise, sonst nichts. und zugriff über index war schon immer teuer (in bezug auf resourcen).
bei oracle gibt es IOT (index organized tables), da ist der index selbst die tabelle. wenn es um query performance (nur I/O) geht, werden häufig die in der query abgefragten spalten in einen index ausgelagert, quasi als teilkopie der tabelle. damit hat man eine IOT emuliert. kostet zwar plattenplatz und performance bei DML aber man kann ja nicht alles haben.
-j
soweit ich weiss ist der primary key als geclusterter index einer tabelle der index, nach dem die daten auch physisch sortiert werden -zumindest beim erstellen-
werden viele daten eingefügt wirkt ein reindex manchmal wunder :cool:
Schon beim Anlegen der Tabelle verwende ich
PRIMARY KEY (foo, foo1),
und auch ein Einspielen des Dumps ändert nichts an der schlechten Performance.