Inoffizielles deutsches Xbase-Forum

georg hat geschrieben:http://www.postgresql.org/docs/8.1/stat ... limit.html

georg hat geschrieben: Ein Limit beginnt mit dem ersten Satz, der durch das entsprechende Statement (gilt sowohl für SELECT, UPDATE, DELETE) ausgewählt wird, und die nachfolgenden, ebenfalls den Kriterien entsprechenden Sätze.

SELECT * FROM table WHERE bedingung LIMIT 50

liefert also die ersten 50 Sätze im Result Set (sofern 50 oder mehr gefunden werden, ansonsten nur die tatsächlichen Treffer, wenn die Anzahl < 50 ist).

SELECT * FROM table WHERE bedingung LIMIT 50 OFFSET 100

liefert 50 Sätze, und zwar aus einem vollständigen Result Set die Sätze 101 bis 150 (sofern mindestens 150 Sätze gefunden wurden).

georg hat geschrieben:P.S.: Du solltest eine Email von mir bekommen haben.

georg hat geschrieben:aus meiner Sichtweise ist es NICHT sinnvoll,

ELSEIF nKey = xbeK_CTRL_PGDN
   ::hide()
   IF ::_nTablelen > 0
      nOff := ::_nTablelen - ::_nMaxRow
      ::_cOffset := LTRIM( STR( nOff ) )
      ::ReadNextData(,,,,, ::_cOffset )
   ELSE
      TONE(1234)
   ENDIF
   ::Show()
   SETAPPFOCUS( self )
   PostAppEvent( xbeBRW_ItemMarked, {::_nMaxRow, 1 },, self )

georg hat geschrieben:das sind wieder Deine esoterischen Fragen ...

georg hat geschrieben:Generell kann man aber davon ausgehen, dass ein SELECT * FROM table ORDER BY sortierung LIMIT x OFFSET y immer dann schnell ist, wenn das angeforderte ORDER BY durch einen Index (z.B. PRIMARY KEY) definiert ist.

ORDER BY __record

LIMIT 30 OFFSET 560788 after 5.90 Sec.
LIMIT 30 OFFSET 560758 after 4.92 Sec.
LIMIT 30 OFFSET 560728 after 3.89 Sec.

UliTs hat geschrieben:Bei detr Gegenprobe sehe ich nirgends das "order by" :-9

ich bin doch auf "__record" welcher der "PRIMARY KEY" ist und "ORDER BY __record"

AUGE_OHR hat geschrieben:...ist der beim öffnen durch pgAdmin.EXE dann nicht auch gleich "aktive" ?

AUGE_OHR hat geschrieben:hi,

Frage : wenn ich eine Table öffne die einen "PRIMARY KEY" hat wird der als "ORDER" genommen oder muss ich das Field, hier __record, noch extra als "ORDER BY " angeben ?

UliTs hat geschrieben:Ist es denn mit Angabe einer Sortierung, zu der es einen Index gibt, in der Gegenprobe schnell?
Uli

UliTs hat geschrieben:

UliTs hat geschrieben:Ist es denn mit Angabe einer Sortierung, zu der es einen Index gibt, in der Gegenprobe schnell?
Uli

Und Jimmy, wie schaut es aus?

AUGE_OHR hat geschrieben:nix, wie ich sagte er "ist" auf dem "PRIMARY KEY" der "__record" heisst und der "natürlichen" Sortierung entspricht...

UliTs hat geschrieben:Ich deute mal Deine Antwort so, dass Du es inzwischen ausprobiert hast, aber es trotzdem langsam ist .

bgl hat geschrieben:Interessant wäre, wie es mit LIMIT/OFFSET in Verbindung mit ORDER BY aussieht, ob du da nach wie vor Probleme hast, wenn du "weiter hinten" in der Tabelle bist.

bgl hat geschrieben:Und es gibt keine natürliche Sortierung nach dem PRIMARY KEY! Nicht vorhanden! Sortiert wird, soweit das die praktische Verwendung angeht, nach dem Zufallsprinzip, wenn du kein ORDER BY verwendest.

AUGE_OHR hat geschrieben:

bgl hat geschrieben:Interessant wäre, wie es mit LIMIT/OFFSET in Verbindung mit ORDER BY aussieht, ob du da nach wie vor Probleme hast, wenn du "weiter hinten" in der Tabelle bist.

mit pgAdmin.EXE oder PGu.EXE ?
PGu.EXE auf dem Notebook < 1 sec (local)

bgl hat geschrieben:Und es gibt keine natürliche Sortierung nach dem PRIMARY KEY! Nicht vorhanden! Sortiert wird, soweit das die praktische Verwendung angeht, nach dem Zufallsprinzip, wenn du kein ORDER BY verwendest.

ich habe die Table gerade vorher erstellt und alle Datensätze importiert wobei ich nextval(***__record) zum hochzählen verwende und "__record" der "PRIMARY KEY" ist.
deshalb sprach ich von "natürlicher Sortierung" -> "__record" Type "serial"

bgl hat geschrieben:Das schlimmste daran: es mag im Test sauber laufen, dann wird es in einer Multi-User-Umgebung genutzt, Datensätze werden parallel geändert und auf einmal wird die Sortierung nach einem "praktischeren" Kriterium (aus Sicht des Servers, nicht aus der des Programms/Anwenders) vorgenommen und dein Programm ist ganz wo anders dran, als du es erwartet hättest.

AUGE_OHR hat geschrieben:reicht dir das als Beweis

AUGE_OHR hat geschrieben:mit kleinen Table ist das nun alle kein Problem aber bei grossen wissen wir ja nun das ein grosser OFFSET viel "Power" braucht.
was auf einem P4 3GHz > 10 Sec. benötigt geht mit einem i7-2630QM in < 0.5 Sec. DAS kann ich vorführen