Schneller?

Hi all.

Weils so schön gefunzt hat, gleich ne neue Frage.
Ich habe nun auf meinem Server Postgre laufen.
Leider ist es aber endlos langsam, was Wartezeiten von mindestens 4 sek erzeugt, was sogar bis 12 sek oder gar keiner rückmeldung manchmal führt.
Das sogar bei nur einem Simplen SELECT der 1 DB mit nur 32k Einträgen durchsucht.

Woran könnte das liegen?

Gruß
Sy-

hi,

hast du einen index angelegt? der punkt 4.6 in der faq konnte dir weiterhelfen (http://www.postgresql.org/docs/faqs.FAQ.html#item4.6)

cu tb.

Nein,

wie mache ich das?
Und muss ich dann bei den Queries was beachten?

naja sinnvoll anlegen :wink: hier mal ein paar links zur doku…

cu tb.

alles klar ich schau mir das mal an.

danke und gruß
Sy-

Hmm, ich meine es zu verstehen.

Dazu hätte ich 2 Fragen

  1. PGAdmin hat mir noch ein “USING btree” dran gehängt, was soll man da unterschiedliches angeben können bzw was hätte das für ein sinn?

  2. Ich habe hier eine DB, die Stück für Stück genauer abgefragt wird:
    erst sp1, dann sp1 und sp2, dann sp1,sp2 und sp3
    bis man bei sp4 angelangt ist, dann hat der eine entsprechende ID.
    Alles schön und gut, aber wie soll ich da nun ein Index bestimmen?

Gruß und danke im Vorraus

  1. b-tree ist das verfahren wie der index angelegt wird. das thema hatten wir schon mal. such einfach mal hier im forum (oben gibt es einen SUCHEN button) oder bei wikipedia.de

  2. naja dann leg einen kombinationsschlüssel an. in der reihenfolge wie du auch die WHERE klausel machst am besten. der datenbankserver hält dir die daten dann entsprechend sortiert vor.

ich persönlich glaube, du hast nicht ganz verstanden was ein index bzw der sinn eines indexes ist. das sollte aber eigentlich aus der doku hervorgehen. die daten werden entsprechend sortiert vorgehalten um eben einen schnelleren, direkten zugriff zu erlauben. das ist nichts neues, revolutionäres von postgresql sondern das hast du in jeder datenbank egal ob mysql, postgresql, mssql, oracle, … oder sogar access…

cu tb.

jo, so hab ich es auch verstanden :wink:

Hab mich damit noch garnicht auseinander gesetzt.
Bei den Daten die ich bei mysql genutzt habe war es nie notwendig.

Meine gedankliche Problematik war halt, dass ich nicht konstant die selben spalten abfrage und somit der index ja nicht mehr 100% sinnvoll ausgelegt wäre, wenn der in den index alle angegebenen spalten einbeziehen würde.
Daher dachte ich, da gibts eine andere Methode oder der bestimmt den Index Spalten unabhängig, sprich für jede Spalte eigener Index.

Nunja, jetzt scheint der mir abgeschmiert zu sein.
Scheint etwas labil zu sein das ganze.
Wie kann ich über SSH(Linux) den mal PG updaten lassen?

Und nochmal zur Kontrolle, das habe ich in meinem Fall nun gemacht:

CREATE INDEX n_sps ON ersatz_n (sp1,sp2,sp3,sp4)

Gruß

naja dann musst du halt u.u. mehrere indexe definieren bzw. den index so aufbauen, das du mit einem teilschlüssel auch zum ergebnis kommst. bei den von dir genannten schlüssel kannst du auch nur die felder sp1 und sp2 mit diesen schlüssel abfragen.

das update kommt drauf an was du für ein linux hast. bei suse mit yast, bei debian/ubuntu mit apt-get, … oder neu kompilieren… da musst du schauen was du für eine distribution hast und dann schauen was es dort für packete gibt.

(btw: mir ist der postgres server noch nie abgeschmiert und ich quäl den teilweise richtig…)

cu tb.

Also Ich habe nun mehrere Indexes drin.

Leider funzt das weiterhin so langsam :cry:
Und manchmal noch diese Aussetzer…

Kann ich noch irgendwas falsch machen? :roll:

Gruß

vielleicht liegt es an deinem system? wenn du schon sagst, das dir der postgres server abstürzt…

was sagen die logdateien deines servers?

cu tb.

Logs sind sauber.

Aber wie ich sehe scheint es am Flash zu liegen.
Wenn ich manuell den Script aufrufe geht es wunderbar.
Versucht es jedoch Flash anzusprechen, dauert es ewig und drei Tage.

Komisch, muss ich da was im vergleich zu MySQL beachten?

Gruß

Alles seltsam hier :wink:

Vielen dank für deine Hilfe, geht mit Index alles viel schneller.
Hatte ein schlechtes Beispiel parat.
War jeweils Flash was da getrödelt hat.

Gruß
Sy-

Im Mysql und in PostgreSQL gibt es den Befehl “Explain”. Man muss ihn nur anwenden!


mfg

fristo

Jo, MySQL startet bei einer Anfrage nur einen neuen Thread, PostgreSQL forked einen kompletten Prozess. Das dauert einfach viel länger.
Bei PHP würde ein pconnect statt connect helfen (hält die Verbindung aufrecht) oder evtl. für Dein Flash-Problem ein SQL-Proxy, der einen festen Verbindungspool bereithält.



Aha, was Wartezeiten von mindestens 4 sek erzeugt, was sogar bis 12 sek oder gar keiner rückmeldung manchmal führt? Wem willst Du so etwas verkaufen?


mfg

fristo

Dir? :lol:

Ne, im Ernst: Ich hatte genau das Problem. Dämliches PHP-Script, das zig SELECTS auf die DB machte. Laufzeit fast 10 Sek auf einem langsamen Rechner. Durch pconnect ist es auf unter 1 Sekunde runter.

Glaubs oder glaubs nicht. Mir wurscht!

Du möchtest und mitteilen, dass das Script für jeden Select eine neue Datenbankverbindung geöffnet hat?

Oder wie soll ich das im Zusammenhang mit den pconnects verstehen?

Hallo Mitterwald,

Ich glaubs Dir ja. Es betrifft speziell Dein Problem.

Aber die allgemeine Aussage, dass es der Unterschied zwischen einen Thread einen kompletten Prozess die Ursache sei, lasse ich nicht gelten. Dafür gibt es zuviele Ursachen.

Wenn Du dir diesen Thread vollständig durchliest, wirst Du feststellen, dass “Sy-” es vermieden hat, sich die Doku anzuschauen. PostgreSQL ist leider nicht MySql.

Hier hatte auch jemand Zeitprobleme: http://www.pg-forum.de/viewtopic.php?t=346&highlight=


mfg

fristo