Wie lange Tabellen auslesen?

[nobody0]

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? :confused:

[Romanday]

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? :confused:

RAM kaufen.

[Turbohummel]

SELECT ..... LIMIT 0,1
SELECT ..... LIMIT 1,2
SELECT ..... LIMIT 2,3
usw.

[nobody0]

SELECT ..... LIMIT 0,1
SELECT ..... LIMIT 1,2
SELECT ..... LIMIT 2,3
usw.

Die Angabe mit dem Komma funktioniert nicht:

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. :)

[Turbohummel]

Achja, SQL-Dialekte ;) Hätte vielleicht mal ganz lesen sollen.

[elrond]

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.. ;)

[nobody0]

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.

[Turbohummel]

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.

[nobody0]

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? :confused:

[Romanday]

Irgendwelche Vorschläge? :confused:

Mein Ratschlag wurde nicht verstanden.
Dann mußt Du den Weg der Schmerzen gehen.:D

[Jinto]

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. ;)

[nobody0]

Wieso sollte bei einfachen Anfragen geswappt werden? :confused:
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.

[elrond]

Das Postgres ist konfiguriert; das wird beim SuSE schon lauffähig installiert.

ja lauffähig und ordentlich konfiguriert sind zwei dinge...

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. ;)

[nobody0]

Und was genau heißt groß?
Welche Muster-Konfiguration empfehlen denn die Experten hier? :confused:

[nobody0]

Aufgefallen ist mir auch, das Postgres auch Minuten nach den Abfragen, also im "Leerlauf", noch heftig auf der Platte arbeitet. Woran kann das liegen? :confused:

[Romanday]

Aufgefallen ist mir auch, das Postgres auch Minuten nach den Abfragen, also im "Leerlauf", noch heftig auf der Platte arbeitet. Woran kann das liegen? :confused:

Ließ dir mal die Antworten von elrond noch 1x durch.:D
(Du hast zuviel Ram im Motherboard, ist doch klar.:D
Planzen wachsen am besten ohne Wasser, Datenbanken
werden schneller ohne RAM. Da hilft nur eine schnellere
Festplatte + 1 lauter Wasserkühler der das Knirschen der
Platte überblubbert. :p)

[Jinto]

Im Programm habe ich vor jedem PQexec ein PQclear, so daß sowohl bei Postgres als auch beim Programm der Speicherbedarf konstant sein sollte.
Behauptungen, nichts als Behauptungen.
Du scheinst meine Thesen nicht verstanden zu haben (in diesem speziellen Fall Punkt 3)

Ich machs mal deutlicher:
Deine Glaube in Ehren, aber es interessiert mich nicht, dass du glaubst du hättest kein Speicherleck, dein Speicherbedarf sei konstant, etc.
Beweise es!

Ausgabe u.a. von: free, top, ps aux
Veröffentlichung des (relevanten) Quelltextes

Es ist ja fast schon ein Wunder, dass du mittlerweile halbwegs Distibution (Version fehlt) genannt hast. Muss man dir alles aus der Nase ziehen, damit man dir helfen kann? Oder sollte ich sagen darf?


Welche Muster-Konfiguration empfehlen denn die Experten hier?Also ich empfehle den Cache auf 8GB zu setzen, dann passt er noch in den Hauptspeicher.:mad:

PS: Dein Ursprungsposting war inhaltlich schon falsch.

[nobody0]

Ich habe nix von Glauben geschrieben; der konstante Speicherbedarf ist mit ps gemessen.

[Jinto]

These:

Ich habe nix von Glauben geschrieben; der konstante Speicherbedarf ist mit ps gemessen.
Widerspruch:


Im Programm habe ich vor jedem PQexec ein PQclear, so daß sowohl bei Postgres als auch beim Programm der Speicherbedarf konstant sein sollte.

Aber auch wenn du das nicht geschrieben hättest. Ohne das du die Fakten (sprich die Ausgabe der entsprechenden Programme) lieferst, ist es in meinen Augen nur dein Glaube den du hier auflistest, denn du gibst nur deine Sicht der Dinge wieder.

Egal, solange du keine Fakten lieferst ist hier für mich EOT.

[nobody0]

Das mit "These" und "Widerspruch" ist Unsinn, denn es dauert einige Tage, die die Programme laufen müssen, bevor man sicher sein kann, dass deren Speicherbedarf konstant ist.