SET RUSHMORE OFF [würde ich mit PGDBE grundsätzlich empfehlen]

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

SET RUSHMORE OFF [würde ich mit PGDBE grundsätzlich empfehlen]

Beitrag von dtmackenzie »

Hier ein bisschen ein Tipp, ein bisschen eine Frage nach Eure Erfahrungen...

Ich hatte in der letzten Zeit einige derartige Fehler in unserer PGDBE Anwendung, dass ich früher (mit ADS oder "nackten" DBFs) korrupte Indexdateien stark in Verdacht gehabt hätte (z.B. auf dem falschen Datensatz nach DBSKIP, aber nur an bestimmten, seltenen Stellen) - es gab sogar verschiedene Erscheinungen, die sich nicht so nachvollziehen lassen, dass ich die je an Alaska hätte melden können (ohne vielleicht unser ganzes System und die Datenbank dazu dorthin zu schicken).

Nun, nachdem ich ein paar PDFs (z.B. 7337 & 7340) gelesen habe, die zwar nicht für PGDBE gemeldet sind aber interessant aussahen, habe ich SET RUSHMORE OFF mit PGDBE probiert, und danach scheinen ein paar solche böse, unerklärliche Problemen weg zu sein. Ich habe dabei noch keinen Performance-Verlust gemerkt.

Vielleicht werde ich auch bei Bedarf SET SMARTFILTER OFF bzw. SET OPTIMIZE OFF weiter probieren, aber bisher scheint SET RUSHMORE OFF das Meiste zu bringen.

Habt Ihr auch sowas gehabt?
Zuletzt geändert von dtmackenzie am Mi, 06. Okt 2021 11:13, insgesamt 1-mal geändert.
Viele Grüße,
David
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SET RUSHMORE OFF

Beitrag von Tom »

Meines Wissens hat die Rushmore-Optimierung nie wirklich verlässlich funktioniert, seit ihrer Einführung. Das ist ja eine Systematik, die aus der FoxPro-Welt kommt und für die von besonderem Interesse ist, aber man muss schon einiges beachten, damit das a) Performance bringt und b) keine Probleme nach sich zieht.

SMARTFILTER mag ich sehr gerne, habe mir aber ähnliche Mechanismen selbst gebaut, die noch etwas spezieller sind. Dabei geht es ja lediglich darum, dass ein Filterausdruck pro Datensatz nur einmal evaluiert wird, und dann merkt sich das Workarea-Objekt, ob dieser Datensatz dem Filter entsprach oder nicht, muss ihn also nicht mehr prüfen - es sei denn, man ändert ihn, dann muss man ein DbRefresh() auslösen, was wiederum alle gemerkten Datensätze für die erneute Evaluierung vormerkt. Das funktioniert perfekt und ist auch kein Wunderwerk, es beschleunigt das Browsen in gefilterten Tabellen mit sehr komplexen Filterausdrücken ganz erheblich. Beim zweiten Mal. :wink:

SET OPTIMIZE habe ich mir schon seit Jahren nicht mehr angesehen. Ist standardmäßig bei uns aus.
Herzlich,
Tom
Antworten