Join und Plan

[Frank Reim]

Ich verstehe die Welt nicht mehr <BR><BR>
Folgender Select:<BR>
select a.*,ar.anrede from adresse a, anrede ar
where a.anrede_id=ar.anrede_id
order by a.adresse_id<BR><BR>
Ohne dem order by wird für den join in Tabelle anrede der index verwendet, alles super...<BR><BR>
mir order verwendet der Optimizer für Tabelle adresse den Index auf das Feld anrede_id anstatt adresse_id und für den join wird kein Index verwendet (natural).
Dadurch dauert der select natürlich entsprechend lange.
Und in Tabelle adresse ist das Feld anrede_id auch über Foraign Key mit Feld anrede_id der Tabelle anrede verknüpft.
Mit anderen Tabellen funktioniert das Problemlos.<BR>
Hat jemand schon mal diese Erscheinung gehabt und gelöst?<BR><BR>
Frank

[Torsten Grundke]

Hallo Frank,

der Optimizer ist leider eine Black-Box (der Sourcecode ist bestimmt öffentlich verfügbar) aber damit er halbwegs funktioniert muß er sehr komplex sein.

Der einfachste Weg besteht darin einfach beim Select den PLAN mit anzugeben.

Gruß

Torste

[Heiko Luettge]

Hallo Frank,<br>
der Optimizer gibt sein bestes (hoffentlich).
<p>
1. Prüfe, ob ein Feld 2 Indizes zugeordnet ist (t.B. über foreign key und eigenen index), wenn ja, lösche den eigenen Index.
<p>
2. nimm die neue join syntax, also<br>
select a.*,ar.anrede from adresse a<br>
join anrede ar on a.anrede_id=ar.anrede_id <br>order by a.adresse_id
<p>
3. Wie viele Einträge sind denn in den einzelnen Tabellen. Firebird sortiert im Speicher. Je nach Tabellengröße baut der Optimizer die Abfrage anders auf.
<p>
4. Prüf mal mit dem planalyzer, wieviel Zeit wirklich benötigt wird.
<p>
Für genauere Infos brauchen wir die Tabellenstruktur, alle Indizes und den erzeugten Plan.
<p>
Heik

[Günter Forster]

Hallo,

vielleicht das gleiche wie bei meinen Abfragen (siehe Thread recomputed bei Interbase).

Schau mal mit IBExpert, ob selektivität irgendwelche Zahlen (0,00034) anzeigt oder nur 0. Dann wird beim sortieren diese tabelle natural benutzt. Ist bei mir bei 2 100MB Tabellen passiert, der select dauerte 20 Minuten.

Lösung : Backup und restore oder im IBExpert 'recompute all indizes').

Gruß Günte

[Frank Reim]

Torsten<BR>
leider kann ich den Plan nicht angeben, da ich mit den Orderlinks von IB-Objects arbeite.<BR>
<BR>
Heiko<BR>
Habe Alles getestet. Tabelle Adresse hat ca. 60000 Datensätze, Abfrage dauert ca. 4 sec.<BR>
Auch join bzw left join (denn hier sollte der Optimizer wissen, dass die Darstellung der Haupttabelle durch den Join nicht beeinflusst wird) bringen keinen Erfolg. Auch Backup und Restore ändern nichts. Ich habe jetzt auf Subselect erst mal umgestellt. Damit kommt der Optimizer klar.<BR><BR>
Günter<BR>
Wilkommen im Club der Leid - geplagten. Bei mir geht das mir recompute leider nicht. Unter Statistik sind auch Werte da.<BR><BR>
Danke an Alle<BR><BR>Fran

[Frank Reim]

Habe es auch mal mit dem neuesten Release von Firebird (1.5 (6)) probiert, ohne Erfolg. Vielleicht brigt ja dem Optimizer doch noch mal jemand das Optimizen bei <BR>
Fran

[Torsten Grundke]

Hallo Frank,

warum behindern Dich die OrderingLinks? Die IB_Query hat doch das Ereignis OnOrderingChanged. Damit bekommst Du mit wenn sich an der order-Klausel was ändert. Jetzt gibt es noch das Property SQLPlan das ebenfalls in der IB_Query vorhanden ist. Jetzt gibts Du deinen manuellen Plan mit an und es sollte funktionieren.

Gruß

Torste

[Frank Reim]

Hallo Torsten,<BR><BR>
ich kann mit IB_Query nicht arbeiten, da ich andere Grids verwende. Und bei IBOQuery gibt es das Event OnOrderingChanged nicht.<BR>
<BR>
Gruß, Fran