Geschwindigkeitsproblem mit Firebird und Devexpress Kalender TcxScheduler

[nit]

Hallo an alle,
wir nutzen Firebird 3 und von Devexpress den Kalender TcxScheduler und haben ein Geschwindigkeitsproblem.
In der Tabelle sind etwas 10013 Datensetze vorhanden und die Abfragezeit liegt bei ca. 23 Sekunden.

Die SQL-Abfrage lautet:
SELECT * FROM KALENDAR WHERE FINISCH>:von AND (AUFGABE<>1 OR AUFGABE is NULL) OR (TYP>0);

Hat jemand eine Ideen, wie man dies schneller machen kann?

Ein Index auf die Spalte FINISCH haben wir auch versucht, aber eine Geschwindigkeitserhöhung nicht feststellen können.

[stifflersmom]

Und die anderen beiden Spalten waren ebenfalls indexiert?

Schon einen kombinierten Index über alle drei abfragerelevanten Spalten versucht?

[ULIK]

Code:

WHERE FINISCH>:von AND (AUFGABE<>1 OR AUFGABE is NULL) OR (TYP>0)

Ist das AND / OR richtig geklammert? Bzw. wie erwartest Du daß es wirkt und tut es dann das auch (gerade in Bezug auf Typ>0)?

[nit]

Es ist ein OR in der Klammer.

Das Ergebnis mit den Testdaten ist richtig, außer es ist Zufall und die Abfrage greift doch nicht.

In der Tabelle werden auch Aufgaben gespeichert. Die Aufgabendatensätze werden immer in der Spalte AUFGABE=1 markiert. In der Spalte mögliche Werte sind 1,0 oder NULL.
Die Spalte Typ gibt an laut der Devexpress, ob der Termin ein Serientermin ist. Die Serientermine können auch kein Ende (FINISCH) haben.
Als Abfrage brauche ich die Datensätze wo ende (FINISCH) größer ist als z.B. 01.01.2024 und keine Aufgabe ist oder einfach wo Typ=1 (Serientermin) ist.

So, denke ich, werden alle relevanten Termineinträge aus der Tabelle geholt.
Andere Abfragevarianten gern willkommen.

[nit]

nein, es ist nur die Index auf die Spalte Finish.

Ich versuche es gleich mal mit dem kombinierten Index.

[t2000]

Bei nur 10.000 Datensätzen spielen Indizes keine große Rolle. Zumindest meine Erfahrung mit Oracle, MSSQL und PostgreSQL
Das Problem wird an einer anderen Stelle liegen.

[himitsu]

Der DX-Sheduler ist aber auch nicht wirklich die schnellste Komponente.
Und lokal sind DB-Indize dann auch nicht mehr von Relevanz.

[IBExpert]

was für eine hardware setzt du für firebird ein? auf eine tabelle mit 10013 datensätzen
ist die struktur der indizes eigentlich ziemlich egal, es sollte niemals irgendwas 23
sekunden brauchen, auch nicht komplett ohne indizes. Wenn die Tabellen struktur
sehr viele lange varchar felder hat könnte es wegen dem temp sort file ggf länger
brauchen aber alles mehr als eine sekunde ist mir da völlig unklar.

hast du mal mit einem tools deiner wahl bei dem sql den plan ermittelt und den
inhalt ohne den Kalender angefragt, möglichst mit fetchall?

weil wenn der kalender das sql ausführt, aber 23 sekunden bis zum malen des kalenders
braucht liegt das problem ganz woanders.

evtl kannst du ja mal die metadaten der tabelle hier posten (und manche tools haben eine
trace api log funktion, mit der man auch sehen kann was firbeird da sonst noch so veranstaltet,
so manch ein computed index kann auch eine katastrophe sein

[Uwe Raabe]

Zitat von nit:

die Abfragezeit liegt bei ca. 23 Sekunden.

Ist es wirklich die Abfragezeit oder die Zeit zum Aufbau des Content?

[nit]

Die reine Abfragezeit ist zwischen 160-220 Millisekunde und hat 8552 Datensätzen als Ergebnis bei nicht verbundener Query-Komponente.

Das Problem liegt irgendwo in der SchudulerDBStorage, sobald der Query-Komponente als Dataset hinterlegt wurde. Ist die gleiche Abfrage bei ca. 23 Sek.

Werde ich mal nächste Woche weitertesten, weil andere Baustellen höher priorisiertet sind.

Danke für die Ideen und Hilfe.