Merkwürdikeit bei Select max(id) from..

[WoGe]

Hallo,

ich habe zum Testen der Performance eine Testtabelle entworfen die 15.000.000 Datensätze enthält.
AR ist die ID und der PrimaryKey

Dabei habe ich folgende überaschende Merkwürdogkeit entdeckt:

SQL-Code:

Select * FROM ROHWERTE
where ar between 14000000 and 14000010

liefert innerhalb von ca. einer 10-tel sec die richtigen Werte zurück
unter Verwendung folgenden Plans: (lt. IBExpert)

Plan
PLAN (ROHWERTE INDEX (PK_ROHWERTE))

Adapted Plan
PLAN (ROHWERTE INDEX (PK_ROHWERTE))

während das hier:

SQL-Code:

Select max(ar) FROM ROHWERTE

unter Verwendung folgenden Plans ca 2min braucht:

Plan
PLAN (ROHWERTE NATURAL)

Adapted Plan
PLAN (ROHWERTE NATURAL)

Was könnte dafür die Ursache sein und wie kann man das Umschiffen?

Viele Grüsse
wo

[mkinzler]

Es gibt ja kein Index für den Maxwert, sondern nur für die Werte, deshalb scheint diese Abfrage ohne den Index ausgeführt zu werden. Versuch mal

SQL-Code:

select first 1 id from rohwerte desc;

[alzaimar]

Zitat:

Zitat von mkinzler

Es gibt ja kein Index für den Maxwert, sondern nur für die Werte, deshalb scheint diese Abfrage ohne den Index ausgeführt zu werden.

Ein halbwegs guter Optimizer/Queryplan-Ersteller sollte aber schon wissen, das MIN/MAX-Aggregate bei geeigneter WHERE-Klausel mit einem Index in O(1) zu holen sind. Insofern halte ich das schon für einen gewaltigen Faux-Pax in Firebird.

[mkinzler]

Zitat:

Ein halbwegs guter Optimizer/Queryplan-Ersteller sollte aber schon wissen, das MIN/MAX-Aggregate bei geeigneter WHERE-Klausel mit einem Index in O(1) zu holen sind.

Sollte er eigentlich.

[WoGe]

Zitat:

Zitat von mkinzler

Es gibt ja kein Index für den Maxwert, sondern nur für die Werte, deshalb scheint diese Abfrage ohne den Index ausgeführt zu werden. Versuch mal

SQL-Code:

select first 1 id from rohwerte desc;

Ausser das Firebird das "desc;" nicht mag, läuft auch dieses Statement nur mit
PLAN (ROHWERTE NATURAL)

[marabu]

Hallo,

gemeint war:

SQL-Code:

select first 1 ar from rohwerte order by ar desc

Grüße vom marabu

[mkinzler]

Hab das hier mit FB2 getestet (Tabelle hatte nur 214 T Einträge ging problemlos.

[WoGe]

@Marabu:

SQL-Code:

select first 1 ar from rohwerte order by ar desc

funktioniert so zwar prinzipiell, aber der Query-Plan bleibt wie gehabt

@mkinzler:
Ich werdemal die Datenbank auf FB2 umstellen, das dauert bei der Menge allerdings eine Weile

Ich werde dann hier weiter berichten.

mfg
wo

[mkinzler]

Welche 1.5x hast du denn?
Eine Migration auf die 2er ist aber unabhängig davon ratsam

[WoGe]

Server version: WI-V6.3.4.4910 Firebird 1.5

Der Backup ist auch gleich fertig, und ich stelle dann auf 2.0 Realease um.
An der Stelle frag ich mich nur noch wenn das besser/richtig funktioniert welche Zugriffskomponeten ich dann in Delphi nehmen soll, da ich den FB1.5 ja wegen der (noch vorhandenen) Kombapilität zu dem Interbase-Kombos von Delphi ausgewählt hatte..

[mkinzler]

Diese Kompatibilität gilt auch für FB2. Allerdings weiß man nicht wie lange noch. Alternativen wären
IBDAC, FIBplus, Zeos, UIB, MDO, ...

[WoGe]

Hallo,

jetzt hab ich folgenden Server : Server version: WI-V6.3.1.12855 Firebird 2.0
und diesen IBExpert: Version 2007.07.20

Leider verwendet der immernoch den PLAN SORT ((ROHWERTE NATURAL))

Besteht die Möglichkeit, das noch irgendwas anderes da Einwirken könnte?

[mkinzler]

Vielleicht die Anzahl der Datensätze. Was für ein Typ hat das Feld?

[WoGe]

Das Feld ist vom Typ Bigint

Die Anzahl der Datensätze habe ich auf ca. 500.000 reduziert.
Zudem habe ich ein Feld Ar2 vom Typ Integer erzeugt und mit dem Inhalt von AR gefüllt und einen Index dazu erstellt.

Auch hier bleibt alles wie gehabt.
Ich werde jetzt noch mal auf 250.000 Sätze reduzieren und AR enfernen.

[TBx]

Das beobachtete Verhalten erklärt sich wie folgt:

Firebird kennt sowohl ascending als auch descending indices.
PKs werden automatisch ascending angelegt.
Um die Max()-Funktion auszuführen, guckt der Optimizer nach, ob es zu dem entsprechenden Feld einen DESCENDING Index gibt. Ist ein solcher nicht vorhanden, so wird gar kein Index genutzt.
Leg Dir also zusätzlich einen descending index auf das Feld, das Du mit der MAX()-Funktion bearbeiten willst und Dein Problem ist gelöst.

Dies ist auch der einzige Weg, die volle Geschwindigkeit zu erhalten.
Verwendet man die Variante mit dem first 1 und der descending order ohne den descending index anzulegen, so ist der db-Server immernoch gezwungen, den vollen Index zu durchlaufen.

Gruß

Thomas

[WoGe]

Super!!!

Zitat:

Zitat von onlinekater

Das beobachtete Verhalten erklärt sich wie folgt:

Firebird kennt sowohl ascending als auch descending indices.
PKs werden automatisch ascending angelegt.
Um die Max()-Funktion auszuführen, guckt der Optimizer nach, ob es zu dem entsprechenden Feld einen DESCENDING Index gibt. Ist ein solcher nicht vorhanden, so wird gar kein Index genutzt.
Leg Dir also zusätzlich einen descending index auf das Feld, das Du mit der MAX()-Funktion bearbeiten willst und Dein Problem ist gelöst.

Das funktioniert genau wie beschrieben, das Problem ist hiermit gelöst.
Der Optimizer verwendet jetzt auf allen mit einem DESCENDING Index versehenen Felder auch diesen und ist entsprechend schnell.

Danke