Meinst du in der firebird.conf?Noch ein Nachtrag:
Bei größeren Abfragen mit Gruppierungen hat sich herausgestellt, dass man die Sort-Einstellungen (Speicherbereiche) auf 8MB/512MB durchaus hochschrauben kann.
Dies brachte bei mir alleine bereits ca. 20% Geschwindigkeitsvorteil.
Ein Foren-Kommentar aus Frankreich
Moderator: martin.koeditz
-
martin.koeditz
- Beiträge: 478
- Registriert: Sa 31. Mär 2018, 14:35
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Exakt:
TempBlockSize = 8M
TempCacheLimit = 512M
Größere Werte erbrachten keinen Vorteil, eher Nachteile.
Einen Index über GroupBy-Felder zu erstellen macht keinen Sinn, da ist ein Tablescan schneller, wenn der Sortbereich groß genug ist.
Indizes sind wichtig für Where- und Join on-Bedingungen.
Hierbei muss man der Firebird etwas helfen, und die Bedingungen gewichten:
Prio 1: =, StartWith, like 'xx%'
Prio 2: >=, between
Rest Prio 3
Z.B.: F1=1 and F2='A' and F3 >= 25
Or-Bedingungen genauer auflösen, auch wenn es mehr Schreibarbeit ist:
a = 'A' and (B = 1 or C = 2) => a = 'A' and B = 1 or a = 'A' and C = 2
Die Firebird splittet die Abfrage und nimmt ggf. 2 Indizes.
Und ab geht die Post.
Noch ein Manko: Bei zu vielen Indizes werden Insert, Updates und Deletes entsprechend langsamer.
TempBlockSize = 8M
TempCacheLimit = 512M
Größere Werte erbrachten keinen Vorteil, eher Nachteile.
Einen Index über GroupBy-Felder zu erstellen macht keinen Sinn, da ist ein Tablescan schneller, wenn der Sortbereich groß genug ist.
Indizes sind wichtig für Where- und Join on-Bedingungen.
Hierbei muss man der Firebird etwas helfen, und die Bedingungen gewichten:
Prio 1: =, StartWith, like 'xx%'
Prio 2: >=, between
Rest Prio 3
Z.B.: F1=1 and F2='A' and F3 >= 25
Or-Bedingungen genauer auflösen, auch wenn es mehr Schreibarbeit ist:
a = 'A' and (B = 1 or C = 2) => a = 'A' and B = 1 or a = 'A' and C = 2
Die Firebird splittet die Abfrage und nimmt ggf. 2 Indizes.
Und ab geht die Post.
Noch ein Manko: Bei zu vielen Indizes werden Insert, Updates und Deletes entsprechend langsamer.
-
martin.koeditz
- Beiträge: 478
- Registriert: Sa 31. Mär 2018, 14:35
Habe die Parameter in der firebird.conf angepasst. Mal sehen, was sich tut.
Ich gehe davon aus, dass die Parameter je Datenbank gelten. Somit muss man aufpassen, dass sich der Server bei mehreren DBs nicht zuzieht, korrekt?
Gruß
Martin
Ich gehe davon aus, dass die Parameter je Datenbank gelten. Somit muss man aufpassen, dass sich der Server bei mehreren DBs nicht zuzieht, korrekt?
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Da bin ich überfragt.
Ich mache Einstellungen in der firebird.config und nicht je DB.
I.d.R. habe ich ja auch nur eine DB.
Bemerkbar wird das aber nur wesentlich, wenn man ein paar 100.000 Zeilen Aggregieren muss, ansonsten wird Sort nicht benötigt.
Übrigens:
Einen Order by verwende ich schon lange nicht mehr, der hält nur auf und führt u.U. zu falschen und langsameren Optimierungen. Die Where/Joins sind am Wichtigsten. Auch ein Grouping passt eher selten zum Where.
Die Sortierung findet meist sowieso im Frontend statt und stimmt eher selten mit der programmierten überein.
In einen Grid oder Dropdown stelle ich da die Grundsortierung ein.
Außerdem sind die Sortfunktionen der Programmiersprache auch schneller, da diese nur im Speicher passieren.
Ich mache Einstellungen in der firebird.config und nicht je DB.
I.d.R. habe ich ja auch nur eine DB.
Bemerkbar wird das aber nur wesentlich, wenn man ein paar 100.000 Zeilen Aggregieren muss, ansonsten wird Sort nicht benötigt.
Übrigens:
Einen Order by verwende ich schon lange nicht mehr, der hält nur auf und führt u.U. zu falschen und langsameren Optimierungen. Die Where/Joins sind am Wichtigsten. Auch ein Grouping passt eher selten zum Where.
Die Sortierung findet meist sowieso im Frontend statt und stimmt eher selten mit der programmierten überein.
In einen Grid oder Dropdown stelle ich da die Grundsortierung ein.
Außerdem sind die Sortfunktionen der Programmiersprache auch schneller, da diese nur im Speicher passieren.