Firebird SELECT IN sehr langsam?

[Gruber_Hans_12345]

Also, ich habe in meinem Code diese SQL Abfrage drinnen, und (fragt mich nicht seit wann) diese ist sehr sehr langsam geworden

SELECT * FROM PERSONAL WHERE ID IN (SELECT PARENTID FROM KOSTEN WHERE PARENTID = 46 GROUP BY PARENTID) wenn ich statt dessen teste mit
SELECT * FROM PERSONAL WHERE ID IN (46) dann gehts in 0 sekunden
und auch die
SELECT PARENTID FROM KOSTEN WHERE PARENTID = 46 GROUP BY PARENTID liefert sofort die richtigen ergebnisse zurück, nur wenn ich die zwei verkette, dann passts nicht mehr - da sprechen wir dann von zeiten zwischen 4 bis 13 sekunden

muß ich da irgendwo noch auf irgendwas aufpassen?, hat sich da bei Firebird >= 2.0 wo was geändert?

[hoika]

Hallo,

ja Subselects sind ab 2.0 irgendwie "nicht mehr so schnell"
Da ist wohl was am Optimizer verschlimmbessert worden.

Das SELECT PARENTID FROM KOSTEN WHERE PARENTID = 46 GROUP BY PARENTI
wird für jedes Id aus Personal aufgerufen (was das Group By hier soll, ist mir schleierhaft)

Ich ersetze solche Sachen meist durch ein left outer join
mit Is Null or Is Not Null.

Das ist unter FB1.5 und FB2.1 gleich schnell.


Heiko

[mkinzler]

Existiert ein Index auf dem Feld KOSTEN.PARENTID?

[Gruber_Hans_12345]

Zitat von hoika:

Hallo,

ja Subselects sind ab 2.0 irgendwie "nicht mehr so schnell"
Da ist wohl was am Optimizer verschlimmbessert worden.

Ich ersetze solche Sachen meist durch ein left outer join
mit Is Null or Is Not Null.

Das ist unter FB1.5 und FB2.1 gleich schnell.


Heiko

das ist aber großer bullshit ... ich brauche solche Sub Select auch für DELETE's, und da gehen ja meines wissen keine JOIN's ... und leider dauern solche Löschaktionen dann so lange, das man das ganze Abbrehcen muß ...

[hoika]

Hallo #,

Ja,
du kannst das ja mal als Bug melden ...

oder auf FB2.5 warten,
vielleicht es ja dann ja behoben.

Bin auch reingefallen,
benutze aber noch 1.5 als Default und die 2.X
zusätzlich als Test.


Heiko

[Gruber_Hans_12345]

Zitat von mkinzler:

Existiert ein Index auf dem Feld KOSTEN.PARENTID?

ja gibt index für alle,

mir kommts aber so vor wie wenn er keinen INDEX für den Primäre SChlüssel bei Personal verwendet da steht dann PLAN NATURAL

gib ichs dann manuell an mit PLAN (PERSONAL INDEX (PERSONAL_ID))
dann sagt er, er kann da keinen INDEX verwenden ...

@hoika
Das GROUP BY war drinnen, da ich orginal ein anderes Feld, mit anderen WHERE rausgeholt habe, und da sind dann 6000 Datensätze, mit immer den selben Werten rausgekomme, deshalb dann das GROUP BY ...

[hoika]

Hallo,

das natural kann schon stimmen.
Er muss ja alle Id's durchlaufen (du hast kein Where oder Order by Personal.Id drin),
da braucht man keinen Index (sagt der Optimizer hier).

Zum Group By

Select Distinct() nehmen.


Vielleicht liegt es ja gerade daran ?



Heiko

[Gruber_Hans_12345]

Habs mal als Bug bei Firebird gemeldet, wenns sich was tut, gib ich hier Bescheid