Ich brauche eine Tabelle in PostgreSQL Zeile für Zeile ausgelesen und weil es ein paar Millionen Zeilen sind, die nicht in das RAM passen, geht das mit SELECT * nicht.
Irgendwelche Vorschläge?
Ich brauche eine Tabelle in PostgreSQL Zeile für Zeile ausgelesen und weil es ein paar Millionen Zeilen sind, die nicht in das RAM passen, geht das mit SELECT * nicht.
Irgendwelche Vorschläge?
RAM kaufen.Zitat von nobody0
Abriss, bzw. die Sprengung des World Trade Centers
WDR Dokumentation
Doku + DT Untertitel
Weitere Infos - Terrorstorm
SELECT ..... LIMIT 0,1
SELECT ..... LIMIT 1,2
SELECT ..... LIMIT 2,3
usw.
Die Angabe mit dem Komma funktioniert nicht:Zitat von Turbohummel
ERROR: LIMIT #,# syntax is not supported
HINT: Use separate LIMIT and OFFSET clauses.
Es geht aber so:
SELECT * FROM foo ORDER BY bar,bar1 LIMIT 1 OFFSET 0;
usw.
Geändert von nobody0 (16-07-2006 um 10:04 Uhr)
Achja, SQL-Dialekte Hätte vielleicht mal ganz lesen sollen.
wenn du die daten effektiv verarbeiten willst, solltest du mit blöcken von datensätzen arbeiten. also "select ... limit 100 offset 0" usw. An dieser stelle mit der Blockgrösse rumzuspielen kann erheblich performance bringen. ob 100 oder 10000 datensätze das optimum sind,kannst du nur testen..
"Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)
Ja, mir ist schon aufgefallen, dass es ohne Blöcke relativ langsam ist.
Wenn es mit Blöcken noch zu langsam ist, kann ich ja noch zusätzlich einen binären Cursor nehmen.
Kommt drauf an was du mit den Datensätzen machst. Wenn du da 20 weitere Updates/Inserts anstößt, machen die eine Query den Bock auch nicht mehr fett.
Also ich lese die Daten nur aus, aber das funktioniert nur bei relativ wenig Zeilen gut; bei einige Millionen wird das Auslesen immer langsamer, obwohl PostgreSQL heftige Platten-Aktivität verursacht und obwohl die Daten mittels
CREATE UNIQUE INDEX data_index ON data (foo, foo1);
geordnet sind und ich mit
SELECT * FROM data ORDER BY foo,foo1 LIMIT %d OFFSET %d
auslese. Ein Speicherleck ist nicht vorhanden.
Irgendwelche Vorschläge?
Mein Ratschlag wurde nicht verstanden.Zitat von nobody0
Dann mußt Du den Weg der Schmerzen gehen.
Abriss, bzw. die Sprengung des World Trade Centers
WDR Dokumentation
Doku + DT Untertitel
Weitere Infos - Terrorstorm
Meiner Theorie nach, hast du 3 Probleme:
1. Du hast Postgres nicht konfiguriert
2. Du hast im Postgres Handbuch die Sektion über die Limit/Offset Funktion übersprungen.
3. Fehlende Beweis deiner Theorien (z.B. "Millionen Zeilen sind, die nicht in das RAM passen, geht das mit SELECT * nicht." oder "Ein Speicherleck ist nicht vorhanden")
Meine Behauptung:
Cache zu grosss eingestellt und das Ding swappt sich zu tode.
Nun gilt es mich zu widerlegen.
Wieso sollte bei einfachen Anfragen geswappt werden?
Im Programm habe ich vor jedem PQexec ein PQclear, so daß sowohl bei Postgres als auch beim Programm der Speicherbedarf konstant sein sollte.
Beim Programm sehe ich auch, dass der Pointer zu den Daten-Blöcken konstant ist.
Das Postgres ist konfiguriert; das wird beim SuSE schon lauffähig installiert.
ja lauffähig und ordentlich konfiguriert sind zwei dinge...Zitat von nobody0
ist der cache der db so gross, dass er nicht in den arbeitsspeicher passt, werden die cache-daten auf die platte ausgelagert; das kostet zeit.
Das ist ein prozess, den du im programm nicht beeinflussen kannst.
"Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)
Und was genau heißt groß?
Welche Muster-Konfiguration empfehlen denn die Experten hier?
Aufgefallen ist mir auch, das Postgres auch Minuten nach den Abfragen, also im "Leerlauf", noch heftig auf der Platte arbeitet. Woran kann das liegen?
Lesezeichen