Performance Einbruch FB 2.5 bei Abfrage auf zusätzliches Feld

[Union]

Die o.a. Queries waren manuell gemacht.

Ich habe eine weitere Lösung erraten:

Code:

cast("POSITION" as Integer)  = 25

Erhöht die Laufzeit nicht.

Code:

"POSITION"   = Cast(25 as smallint)

aber sehr wohl. Es hat scheints nicht so viel mit dem reservierten Namen (der allerdings durch das Quoting entschärft wurde) zu tun, sondern mit dem Vergleich bei unterschiedlichen numerischen Datentypen (SMALLINT / INTEGER).

[Delphi.Narium]

Eine eher befremdlich wirkende Variante:

SQL-Code:

select
    lt.art,
    lt.Pos,
    lt.textline
from sendpos
left outer join lscoll on
  lscoll.lskopf_id = sendpos.lskopf_id
inner join lspack on
      lspack.lskopf_id = lscoll.lskopf_id
  and lspack.colli_nr  = lscoll.colli_nr
inner join (
  select
    lspos_id, art, "POSITION" as Pos, textline
  from lsptext -- hier erstmal aus der Tabelle lsptext das rausfiltern, was wir garantiert benötigen
  where "POSITION" = 25
  and art in ('G1', 'G2', 'G3', 'G4', 'G5', 'G6', 'D1', 'D2', 'D3', 'D4', 'D5')
) lt on
   lt.lspos_id = lspack.lspos_id
where sendpos.sendk_id = 101821515

Unter Oracle hab' ich mit solchen Konstrukten in der Vergangenheit zuweilen schonmal ein paar Stunden sparen können (es ging aber auch in den Bereich von 100 bis 200 Mio. Datensätzen)
Ob sich Firebird mit solchen Konstrukten beschleunigen lässt, weiß ich nicht, es könnte daher also auch nach hinten losgehen.

Überspitzen könnte man es dann mit:

SQL-Code:

select
    lt.art,
    lt.Pos,
    lt.textline
from (
  select 
    lskopf_id
  from sendpos 
  where sendpos.sendk_id = 101821515 -- Menge möglichst klein halten vor dem Join mit anderen Tabellen.
) sp
left outer join lscoll on
  lscoll.lskopf_id = sp.lskopf_id
inner join lspack on
      lspack.lskopf_id = lscoll.lskopf_id
  and lspack.colli_nr  = lscoll.colli_nr
inner join (
  select
    lspos_id, art, "POSITION" as Pos, textline
  from lsptext -- hier erstmal aus der Tabelle lsptext das rausfiltern, was wir garantiert benötigen
  where "POSITION" = 25
  and art in ('G1', 'G2', 'G3', 'G4', 'G5', 'G6', 'D1', 'D2', 'D3', 'D4', 'D5')
) lt on
   lt.lspos_id = lspack.lspos_id

Kann was bringen, muss aber nicht, je nach Datenmenge in den "Zwischenergebnissen".

Was meinst Du mit Datenmenge ist 1 ?
Ergebnismenge oder Gesamtdatenbestand?

[Union]

Das Resultset enthält nur einen Satz. Ich habe es aber gelöst. Es lag an dem Vergleich SMALLINT / INTEGER.

Die Datenmengen

SENDPOS 1195320

LSCOLL 1367358

LSPOS 11404522

LSPACK 10821130

LSPTEXT 7165841

Das Ausführen der Query ohne den Vergleich auf das Feld POSITION mit 25 ergibt (0,6 s):

Code:

G1 25  LI-Gép - Közúti/tengeri - ragassz "Közúti/tengeri" LI matricát a kollira

[Blup]

Ich vermute das Problem nicht in der Typ-Umwandlung.

Laut Plan benutzt die Abfrage für den Zugriff LSPTEXT Index (LSPTEXT_LSPOS_ID, LSPTEXT_POSITION).
LSPTEXT_POSITION hat wahrscheinlich eine schlechte Selectivität.
Alle Datensätze die LSPTEXT_LSPOS_ID liefert, werden mit allen Datensätzen aus LSPTEXT_POSITION verglichen und die Schnittmenge gebildet.
Das dauert länger als bei allen Datensätzen aus LSPTEXT_LSPOS_ID direkt das Feld "POSITION" zu prüfen.
Auf die Schnittmenge wirkt dann erst die Bedingung für lsptext.art.

"POSITION" ist als smallint definiert, durch die Typumwandlung vor dem Vergleich kann der Index LSPTEXT_POSITION nicht mehr angewendet werden.

Der Index "LSPTEXT_POSITION" macht in dieser Tabelle keinen Sinn.
Ich kann mir keine Abfrage vorstellen, die "POSITION" erfordert, aber bei der "LSPOS_ID" nicht berücksichtigt wird.
Hier ist ein kombinierter Index über "LSPOS_ID" und "POSITION" effektiv und kann den INDEX LSPTEXT_LSPOS_ID und LSPTEXT_POSITION ersetzen.

[Union]

@blup
Deine Vermutungen sind hier nicht zutreffend. Denn wenn die Bedingung

Code:

cast("POSITION" as Integer) = 25

0,6 s dauert und

Code:

"POSITION" = 25

5 s dann liegt es nicht am Index. Für Sonderfälle sind zusammengesetzte Indizes bestimmt gut, ansonsten ist FB meiner Erfahrung nach sehr gut in der Lage, sich den Zugriffsplan aus einzelnen Feldindizes zusammenzubauen..

[Blup]

Ganz im Gegenteil, durch die Typumwandlung greift der Index LSPTEXT_POSITION nicht mehr.
Das kannst du sicher im Ausführungsplan nachschauen.
Ein unnötiger Index wenig, in diesem Fall = schneller.