Index setzen?

[Gruber_Hans_12345]

ja stimmt schon
nur habe ich auch ähnliche Anwendungsfälle, wo ich dann unterschiedliche Buchungen pro User haben möchten
zB.: generelle die letzte hinzugefügte Buchung
oder die jüngste Buchung (ID und das Datum müssen nicht übereinstimmen - sprich ich kann jetzt eine Buchung mit einem alten Datum erzeugen) - und je nach Situation ist einmal diese Buchung und einmal die andere Buchung als letzte "interessante" Buchung wichtig.
Oder spezielle Buchungen dann doch ausblednen und somit die ID der jüngsten Buchung die als Typ nicht 8 hat ....

Dann benötige ich für jeden dieser spezial Sachen wieder eine eigene Spalte

[NicoDE]

Zitat von tsteinmaurer:

Firebird kann keinen DESCENDING Index für ein GROUP BY verwenden:
http://tracker.firebirdsql.org/browse/CORE-4529

Es fehlt ein "ORDER BY x DESC", um den Index zu verwenden.

[jobo]

Zitat von Gruber_Hans_12345:

nur habe ich auch ähnliche Anwendungsfälle, wo ich dann unterschiedliche Buchungen pro User haben möchten..
Dann benötige ich für jeden dieser spezial Sachen wieder eine eigene Spalte

Tja, das klingt nun aber auch schon etwas schräg. Buchungen irgendwo dazwischenschieben.. naja, wenn 's sein muss.

Wenn es nunmal eine Anforderung ist:
Hier könnte man vielleicht mit Snapshots / Materialized Views arbeiten, wenn fb das kann. In 3 vielleicht?

Oder den Trigger, der die Aggregatinfo sammelt etwas intelligenter machen. Das meiste dürfte besser sein als dieses Brute Force GROUP BY.

@NicoDE
Ist das wirklich so? Was soll ein Group By mit einem solchen Index anfangen? Ich kann mir nicht vorstellen, dass das hilft.

[NicoDE]

Zitat von jobo:

Was soll ein Group By mit einem solchen Index anfangen?

Man kann die Verwendung des Indizes so 'ermöglichen'. Ansonsten könnte man den Plan/Index explizit angeben und es damit 'erzwingen' (dann muss der Index aber auch existieren und Firebird kann sich nicht mehr anders entscheiden).

Ob das Anlegen und die Verwendung des Indizes Sinn macht oder nicht, ist eine andere Frage (beim Beispiel im Firebird-Tracker nur, wenn man ohnehin sortieren will).

[tsteinmaurer]

Zitat:

Man kann die Verwendung des Indizes so 'ermöglichen'

Die Verwendung eines Index ist nicht immer gleichbedeutend mit schneller.

[Gruber_Hans_12345]

Zitat von NicoDE:

Zitat von tsteinmaurer:

Firebird kann keinen DESCENDING Index für ein GROUP BY verwenden:
http://tracker.firebirdsql.org/browse/CORE-4529

Es fehlt ein "ORDER BY x DESC", um den Index zu verwenden.

Ohhh tatsächlich
mit dem ORDER BY dauert es nun statt 4,0 sekunden 1,2 sekunden !!!!!

Wobei das ganze nun für mich irgendwie noch schräger wird!

Also ohne dem ORDER BY bekomme ich als Plan nun "PLAN (BUCHUNGEN_DATUM ORDER BUCHUNGEN_USERID)" verwendet den Index.
mit ORDER BY USERID DESC : "PLAN SORT ((BUCHUNGEN_DATUM NATURAL))" - da ich ja keinen DESC Index für USERID habe aber das ganze ist trotzdem 3 mal schneller!
mit ORDER BY USERID ASC : "PLAN (BUCHUNGEN_DATUM ORDER BUCHUNGEN_USERID)" hier verwendet er den Index für UserID und ist langsam!

Also sieht es so aus als ob es genau umgekehrt ist, sobald ich ihn zwinge keinen Index zu verwenden dann wirds schneller!

[edit] für den gegentest habe ich den Index auf USERID nun mal gelöscht, nun sind alle gleich schnell bei 1,3 Sekunden sowas....

[jobo]

@NicoDE/TE
Es gibt viele Fragen zu dem Thema, wie kann ich eine Indexverwendung erzwingen. Diese Fragen stellen sich zu Recht, wenn der Optimizer aus verschiedensten Gründen zu falschen Annahmen kommt. Dafür gibt es einerseits dann "Tricks", ich sag mal, um den Optimizer zu "übertölpeln" andererseits sogar Implementierungen mit spezielle Notation (meist herstellerspezifisch), denn die Hersteller wissen, dass es manchmal sinnvoll sein kann.

Wenn die Aufgabe aber lautet:
"Zähle alle Daten der Tabelle" (ohne Einschränkung/Where Clause/ Join Einschränkung) kommt der Optimizer zu Recht zu dem Schluss: Wenn ich eh alle Daten zählen muss, kann ich das auch "ganz bequem" von Anfang bis Ende mit einem (1!) Fulltablescan machen.
Der Zwang zum Index würde dazu führen, dass "die arme Engine" je Index Eintrag durch die Tabelle hüpfen muss, um am Ende zu dem überall mal hingesprungen zu sein und zu dem gleichen Ergebnis zu kommen, wie bei einem Fulltablescan ohne Index.

Dabei unberücksichtigt sind natürlich spezielle Indexverfahren oder aber auch die bereits gecachten Tabellenbestandteile. Letztere könnten dem Optimizer bspw. sagen, ich hab eh 90% der Daten im Cache, die 10% lade ich auch noch. Dann ist ein Fulltablescan (plus ggF. Sortierung) lediglich "Kopfrechnen" und sowieso vorzuziehen. Der Ausgang dieser Optimizerentscheidung wird wiederum von der Größe der Tabelle und der Cachegröße und der Häufigkeit der Verwendung der Tabelle abhängen.
Es gibt eine Fülle solcher Kriterien, die es oft schwierig machen, Optimizerentscheidungen nachzuvollziehen- auch sehr unterschiedlich je Produkt und Version.
Hier ist die Sache aber finde ich relativ klar.

Der Ansatz mit Trigger ist relativ naheliegend, auch wenn er noch ausgefeilt werden müsste. Wie mkinzler schon betont hat, der "Impakt" einer solchen Lösung dürfte auch bei relativ hoher Buchungsfrequenz bedeutend geringer ausfallen, als der Aufwand der hochfrequenten Fullscan-Abfragen.

[tsteinmaurer]

Zitat:

Also sieht es so aus als ob es genau umgekehrt ist, sobald ich ihn zwinge keinen Index zu verwenden dann wirds schneller!

Habe ich dir in meinem ersten Posting schon gesagt

Bei einem Full-Table-Scan wird dann halt die Response-Time variieren, abhängig davon wie die Caches (OS Filesystem, Firebird Page Cache) befüllt sind. Des weiteren auch, ob Firebird für die implizite Sortieroperation bei einem GROUP BY für temporäre Sachen auf die Disk gehen muss oder alles in den konfigurierten RAM bringt.

[Gruber_Hans_12345]

Zitat von tsteinmaurer:

Zitat:

Also sieht es so aus als ob es genau umgekehrt ist, sobald ich ihn zwinge keinen Index zu verwenden dann wirds schneller!

Habe ich dir in meinem ersten Posting schon gesagt

Bei einem Full-Table-Scan wird dann halt die Response-Time variieren, abhängig davon wie die Caches (OS Filesystem, Firebird Page Cache) befüllt sind. Des weiteren auch, ob Firebird für die implizite Sortieroperation bei einem GROUP BY für temporäre Sachen auf die Disk gehen muss oder alles in den konfigurierten RAM bringt.

Ja stimmt
Für die zeiten führe ich immer zuerst 1-2 mal die Abfrage aus ohne zu messen und dann nehme ich das mittel aus 3-5 abfragen damit ich Last die durch andere verursacht werden nicht so sehr ins Gewicht fallen.

Aber schön das ich endlich mal ein Beispiel finde (aus der Praxis), wo ein Index (der zwar für andere Sachen wichtig ist) so richtig kontraproduktiv ist.

[tsteinmaurer]

Beim Testen nicht vergessen, dass auch alle Datensätze gefetched werden und nicht nur Top X, z.b. durch ein Daten-Grid. Das kann den Unterschied Index vs. Full-Table Scan nochmal anders darstellen