ORDER in Unterselect sehr langsam

[Gruber_Hans_12345]

Hallo, ich verwende folgendes Statemant

SQL-Code:

SELECT P.ID, (SELECT FIRST 1 TB.AUFTRAGID FROM TERMINAL_BUCHUNGEN TB WHERE TB.PERSONALID = P.ID ORDER BY TB.BUCHUNG DESC) AS AUFTRAGID
FROM PERSONAL P

als Plan bekomme ich folgendes raus

Code:

PLAN (TB ORDER TB_BUCHUNG INDEX (TB_PERSONALID))
PLAN (P NATURAL)

würde eigetnlich gut aussehen, aber leider ist es sehr langsam (5 Sekunden)

im vergleich ohne dem ORDER

SQL-Code:

SELECT P.ID, (SELECT FIRST 1 TB.AUFTRAGID FROM TERMINAL_BUCHUNGEN TB WHERE TB.PERSONALID = P.ID) AS AUFTRAGID
FROM PERSONAL P

als PLAN

Code:

PLAN (TB INDEX (TB_PERSONALID))
PLAN (P NATURAL)

und benötigt ca. 100 ms

das problem ist, das ich dieses statemant sehr oft aufrufen muß, ... und dadurch macht sich diese 5 sekunden sehr bemerkbar

weiss jemand wie ich das beschleunigen kann?

[WoGe]

Zitat von Gruber_Hans_12345:

Code:

TB.BUCHUNG DESC

ist darauf ein Index?

[Gruber_Hans_12345]

ja ist

habe es im ORDER auch mit TB.ID prboiert, das ist der PRIMARY KEY und auch bei dem ist es gleich langsam

da bekomme ich folgenden PLAN

Code:

PLAN (TB ORDER RDB$PRIMARY87 INDEX (TB_PERSONALID))
PLAN (P NATURAL)

[rweinzierl]

Hallo

Du kannst ja beim Select den Plan mit angeben ==> Vielleicht wirds dadurch schneller

mfg

Reinhold



-----------
Dokumentation der Arzneimittel www.ithof.de

[Gruber_Hans_12345]

Zitat von rweinzierl:

Hallo
Du kannst ja beim Select den Plan mit angeben ==> Vielleicht wirds dadurch schneller

Und was gebe ich ihm al sPLAN an, damit er schneller wird?

bzw. gibt es irgendwoi eine doku, wann FB für einen ORDER einen Index verwendet und wann nicht?!?!?

[rweinzierl]

Hallo

Sorry hab deine Meldung nochmals genau gelesen.

Ich dachte der Plan der 100 ms Lösung könntest du verwenden, der ist jedoch ohne Order by ...


Als nächstes würde ich eine View mit eben der aktuellsten Auftragsid pro Buchung testen.


==> Wenn das auch nichts hift könnte man noch die Daten (aktuelle Auftragsid pro Buchung) in eine Hilfstabelle schreiben.
Klar wiederspricht der Grundregel keine berechenbaren Daten speichern, aber schnell wird das auf alle Fälle.

mfg

Reinhold

[Gruber_Hans_12345]

Zitat von rweinzierl:

Hallo

Sorry hab deine Meldung nochmals genau gelesen.

Ich dachte der Plan der 100 ms Lösung könntest du verwenden, der ist jedoch ohne Order by ...


Als nächstes würde ich eine View mit eben der aktuellsten Auftragsid pro Buchung testen.


==> Wenn das auch nichts hift könnte man noch die Daten (aktuelle Auftragsid pro Buchung) in eine Hilfstabelle schreiben.
Klar wiederspricht der Grundregel keine berechenbaren Daten speichern, aber schnell wird das auf alle Fälle.

mfg

Reinhold

Also in eine Zusatztabelle möchte ich es nicht speichern, wird wieder sehr komplex, da pro aufrag mehr als eine person angemeledt sein kann, und eine person wieder auf mehreren aufträgen ....

Ich hätte auch schon probiert die SELECT in SELECT in eine plain SELECT (also mit Joins umzubauen) aber das bringe ich auch irgendwie nicht zusammen
Den soviel ich bisher merken konnte hat der Firebird noch oft probleme, so wie mit dem IN ...

[hoika]

Hallo,

Zitat:

gibt es irgendwoi eine doku, wann FB für einen ORDER einen Index verwendet und wann nicht?!?!?

Das entscheidet der Optimizer bei jeder Query separat.

SQL-Code:

SELECT P.ID, (SELECT FIRST 1 TB.AUFTRAGID FROM TERMINAL_BUCHUNGEN TB WHERE TB.PERSONALID = P.ID ORDER BY TB.BUCHUNG DESC) AS AUFTRAGID
FROM PERSONAL P

Was willst du denn eigentlich erreichen ?

Hast du auf TERMINAL_BUCHUNGEN.BUCHUNG auch einen DESC Index ?
Ein normaler (ASC) reicht nicht.

Ich würde das SubSelect eh weglassen.
Wie du richtig festgestellt hast, at FB du schon noch Probleme.

Mach es doch etwa so

SQL-Code:

Select Max(TB.BUCHUNG) AS AUFTRAGID, PersonalId
From FROM TERMINAL_BUCHUNGEN
Group By PersonalId

Grouping ist meine grosse Schwäche
Ob dann noch ein Desc Index auf TERMINAL_BUCHUNGEN.BUCHUNG notwendig ist,
musst du ausprobieren.
Auf TERMINAL_BUCHUNGEN.PERSONALID sollte aber einer draufsein.


Heiko

[Gruber_Hans_12345]

Zitat von hoika:

Hallo,

Zitat:

gibt es irgendwoi eine doku, wann FB für einen ORDER einen Index verwendet und wann nicht?!?!?

Das entscheidet der Optimizer bei jeder Query separat.

SQL-Code:

SELECT P.ID, (SELECT FIRST 1 TB.AUFTRAGID FROM TERMINAL_BUCHUNGEN TB WHERE TB.PERSONALID = P.ID ORDER BY TB.BUCHUNG DESC) AS AUFTRAGID
FROM PERSONAL P

Was willst du denn eigentlich erreichen ?

Hast du auf TERMINAL_BUCHUNGEN.BUCHUNG auch einen DESC Index ?
Ein normaler (ASC) reicht nicht.

Ich würde das SubSelect eh weglassen.
Wie du richtig festgestellt hast, at FB du schon noch Probleme.

Mach es doch etwa so

SQL-Code:

Select Max(TB.BUCHUNG) AS AUFTRAGID, PersonalId
From FROM TERMINAL_BUCHUNGEN
Group By PersonalId

Grouping ist meine grosse Schwäche
Ob dann noch ein Desc Index auf TERMINAL_BUCHUNGEN.BUCHUNG notwendig ist,
musst du ausprobieren.
Auf TERMINAL_BUCHUNGEN.PERSONALID sollte aber einer draufsein.


Heiko

Hallo also ich habe mittlerweile auf fast jedes Feld 2 Indexe einen ASC und einen DESC (zum testen)
Die tabelle hat ja auch mittlerweile schon über 8 Millionen einträge ...

Das Problem ist ja, eine normales Group bringt nicht die werte die ich brauche, da ich ja
den Wert AUFTRAGID aus der Tabelle TERMINAL_BUCHUNGEN brauche der am aktuellesten ist (sprich TB.BUCHUNG am ältesten)
(in der echt applikation sind noch ein paar WHERE dabei, aber die machen keinen Unterschied aus)

wenn eis ein
SELECT (TBAUFTRAGID BY MAX(TB.BUCHUNG)) oder so geben würde
sprich eine Aggreagatfunktion, die mir die Spalte AuftragID zurückliefert, von der Zeile, wo MAX(TB.BUCHUNG) das wäre ideal .... sowas kann ich meines erachtens nur mit so nem (SELECT FIRST 1 ... ) erreichen, ansonsten würde ich es auch in ein GROUP umbauen ...

[hoika]

Hallo,

das hatte ich BUCHUNG, AUFTRAGID in der Struktur übersehen.
Naja, zur Not ne SP erzeugen.


Auf jeden Fall ist die Tabelle Personal unnötig,
da die PersonalId ja schon in der Tabelle TERMINAL_BUCHUNGEN steht.


Heiko