PostgreSQL LIMIT / OFFSET [erledigt]

Alles zum SQL-Dialekt

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL LIMIT / OFFSET

Beitrag von AUGE_OHR »

brandelh hat geschrieben:außer der SERVER könnte erkennen was er schon durchsucht hat und den Befehl direkt auf dem OFFSET weiterführen :?:
jajaja so was suche ich ... aber das gibt es wohl nicht in der v8.x. in der v9.x API gibt es ja paar neue Sachen ...
brandelh hat geschrieben:TIP: Wenn der schnellste Rennwagen zu langsam wird, sollte man über einen kürzeren Weg nachdenken :badgrin:
ne [-X dann erhält man eine 20 Sec. Zeitstrafe wie Vettel wenn man die Strecke "mit allen 4 Reifen" verlässt ;)



die ganze "native" Fragen Serie diente ja nur als Vorspiel zu pgDBE denn damit wird ein "normaler" Xbase++ User,
der auf PostgreSQL umstellen möchte, ja arbeiten wenn es released wird.
die "Regeln" legt also quasi pgDBE fest was wir machen können wobei ja alles "erlaubt" sein soll was wir von anderen DBEs "gewohnt" sind.
wenn pgDBE wirklich so toll wäre wie man uns es manchmal verkaufen will dann hätte ich auch keine Fragen.

der letzte simple Testcode zeigt schon das deutliche Verhalten von pgDBE bei grossen Table.
wenn ich in der DBF ein DbGoTop() mache ist das doch genau so schnell wie DbGoBottom() oder einem anderen DbGoto()
das pgDBE Demo zeigt nun das Verhalten wie es mit grossen OFFSET auch in der "native" Version passiert.

Fazit : das ist "System" bedingt.

ein anderer Test mit DbCreateIndex() -> crash ... "out of Memory" ( 1.76GB von 8GB ) oder REINDEX sind unbefriedigend [-X .

Fazit : da muss Alaska "nacharbeiten"

p.s. ob DbCreateIndex() / REINDEX überhaupt "Sinn" macht will ich hierbei gar nicht betrachten
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL LIMIT / OFFSET [erledigt]

Beitrag von AUGE_OHR »

Nachtrag "Power" : ich habe eine "mögliche" Erklärung gefunden ... pgAdmin.EXE erzeugt nicht genügend "Last" ;)

zunächst hab ich pgAdmin.exe auf 1 x CPU "begrenzt" ... die "Last" ging ein wenig hoch aber nicht genug.
dann wollte ich den n! ( Fakultät) Trick anwenden aber der funktioniert unter Win7 x64 nicht mehr ?
ok dann eben den Win 7 Benchmark Test ... und siehe da pgAdmin.exe war bis zu 30% schneller !!!

man muss dazu nun bemerken das die i5 / i7 Reihe ja die "Turbo" Funktion haben wobei die Notebooks bis 800Mhz runter takten.

also dachte ich ... es muss doch irgendwo die Einstellungen da für geben ... a ja unter Energie war das doch
NB_100.PNG
NB_100.PNG (211.15 KiB) 6111 mal betrachtet
aber was ist das ? nicht schneller ? :banghead:

na gut es waren alle CPUs an. also mal alle bis auf CPU 0 abschalten und nochmal ... CPU ist im Turbo Modus aber zeigt kaum "Last" ... na ja 5-6% vielleicht aber der alter P4 macht es in 1/3 (!) der Zeit :shock:
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL LIMIT / OFFSET

Beitrag von brandelh »

AUGE_OHR hat geschrieben:die ganze "native" Fragen Serie diente ja nur als Vorspiel zu pgDBE denn damit wird ein "normaler" Xbase++ User,
der auf PostgreSQL umstellen möchte, ja arbeiten wenn es released wird.
Ich denke aber, dass deine Überlegungen in die falsche Richtung gehen.
Der "normale" Xbase++ User der "Upgrade SQL" (oder wie es auch heißen wird) nutzt,
der nimmt die normalen Xbase++ Befehle und die pgDBE.
Vielleicht wird er beim USE noch den SELECT reinmogeln, aber er muss nicht wissen wie Alaska die Kompatibilität erreicht hat.
Die DBEs sollen ja gerade nach außen eine blackbox sein.
Internas der Umsetzung in einer Version besonders einer Beta zu erkunden ist für dich sicher eine Herausforderung,
keinesfalls sollte man aber davon ausgehen, dass das Verhalten dieser Internas immer gleich bleibt und
darin herumzudoktern würde ich keinem "normalen" Xbase++ User empfehlen.

Wer Performance will, muss sich dann Gedanken darüber machen wie man dem Server das Leben erleichtert,
das können SERVER Indexe sein, ganz wichtig wird es sein nicht mit SELECT * alle Felder zu laden und schon gar nicht unnötige Datensätze.
Dass SQL Server der 5 Anwender so nebenbei bedient eine andere Hardware benötigt (das macht mein Desktop im Hintergrund) als einer der
100 oder mehr Anwender versorgen muss, sollte jedem klar sein.

Wenn es dann um Datenmengen von 500.000 Datensätzen beim Import geht, dann wird es wieder spannend ;-)
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL LIMIT / OFFSET

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Ich denke aber, dass deine Überlegungen in die falsche Richtung gehen.
Der "normale" Xbase++ User der "Upgrade SQL" (oder wie es auch heißen wird) nutzt,
der nimmt die normalen Xbase++ Befehle und die pgDBE.
Vielleicht wird er beim USE noch den SELECT reinmogeln, aber er muss nicht wissen wie Alaska die Kompatibilität erreicht hat.
Die DBEs sollen ja gerade nach außen eine blackbox sein.
YUP soweit alles klar ich stimme dir voll zu.
brandelh hat geschrieben:Internas der Umsetzung in einer Version besonders einer Beta zu erkunden ist für dich sicher eine Herausforderung,
keinesfalls sollte man aber davon ausgehen, dass das Verhalten dieser Internas immer gleich bleibt und darin herumzudoktern würde ich keinem "normalen" Xbase++ User empfehlen.
halt ... hier hast du einen grossen Sprung gemacht.

ich "wollte" ja die blackbox nutzen ohne SQL "Kenntnisse" und das sind wohl die meisten die noch kein SQL System haben.

also hab ich mit der MDIDEMO angefangen und versucht mich zu steigern bis die Fehlermeldungen kamen.
das Alaska im Forum auf meine Fragen nicht hinreichend beantwortet hat hab ich zunächst das ganze in die Ecke geschmissen.

nun kam der die Ankündigung des Chart, mit dem falschen Termin, also hab ich den Kram wieder raus geholt.
inzwischen hab ich aber mit Phil Ide´s alter "native" PostgreSQL Class gearbeitet und mich in die Syntax (ZSTRING) der ot4xb eingearbeitet.
ich hätte also im Chart "präzise" Fragen stellen können ... und vielleicht Antworten bekommen.

das "Reengineering" wurde wegen der fehlenden API notwendig da man es ja nicht für nötig empfand auf auf entsprechende Nachfrage zu reagieren.
tatsächlich gibt es für die DBE eine API Beschreibung und 2 Leute, nicht Alaska, haben die wohl ...

durch diesen Thread und die anderen Diskussionen ist mir nun klar was "System bedingt" möglich ist und kann eher beurteilen ob pgDBE "vernünftig" arbeitet was REINDEX sicherlich nicht der Fall ist. ( technisch ok denn er zieht das ja durch)

ob die "Index" Geschichte überhaupt mit pgDBE einen Sinn macht sollte im anderen Thread "Index" weiter besprochen werden.
brandelh hat geschrieben:Wer Performance will, muss sich dann Gedanken darüber machen wie man dem Server das Leben erleichtert ...
oder seine Pläne runter schrauben ...

bis 1000000 Datensätze hab ich mit DBF Dateien "noch" keine Probleme, aber das 10 x fache war meine Vorstellung.
sicherlich braucht man nicht alle auf einmal. Ich habe deshalb auch meine DBF "mehrstufig" besonders bei "Bewegungs-" Dateien.

die "Umstellung" auf pgDBE wir also "technisch" mittels einiger Zeile für die DBE Session abgeschlossen sein,
aber damit hat man in etwa so viel wie mit einem Cl*pper Source der sich gerade zusammen linken liess zu eriner 32bit Application...
die "Konzept Umstellung" auf GUI ist damit noch nicht vollzogen sondern jetzt würde die Arbeit erst anfangen.

soviel ist klar : es wird eine komplett neue Anwendung wenn man auf pgDBE umstellen will.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL LIMIT / OFFSET

Beitrag von brandelh »

AUGE_OHR hat geschrieben:das "Reengineering" wurde wegen der fehlenden API notwendig da man es ja nicht für nötig empfand auf auf entsprechende Nachfrage zu reagieren.
tatsächlich gibt es für die DBE eine API Beschreibung und 2 Leute, nicht Alaska, haben die wohl ...
Wenn die pgDBE so PostGreAQL-API abhängig sein sollte wie du es hier schreibst (ich kann das nicht beurteilen), dann werde ich diese NIE einsetzen.
Gerade bei meiner HBPrintPDF Klasse komme ich kaum den neuen Versionen von QuickPDF hinterher, wie soll man da als Entwickler für verschiedene Zielsysteme
den Überblick über die nötige API des SQL Servers behalten ...
:arrow: gerade daher kann ich es mir aber auch nicht vorstellen, dass Alaska die wirklich getan hat ! 8)
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL LIMIT / OFFSET

Beitrag von AUGE_OHR »

brandelh hat geschrieben: :arrow: gerade daher kann ich es mir aber auch nicht vorstellen, dass Alaska die wirklich getan hat ! 8)
xfree.public, Re: PostgreSQL LIMIT OFFSET on big Table.

ich kann die Antwort von S.E. nur zitieren das die beiden von Alaska eine DBE (!!!) API bekommen haben um PostgreSQL einzubinden.
es geht also um die Alaska DBE API damit man eigene DBE schreiben kann wenn man mit pgDBE nicht zufrieden ist ...
gruss by OHR
Jimmy
Antworten