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