Firebird Leistung Index Max

[tsteinmaurer]

Mit COUNT(*) fragst du nach der Anzahl aller Datensätze. Warum soll da Firebird über einen Index gehen, wenn er sowieso alle Datensätze besuchen muss?

[haentschman]

:lol: Prinzipiell schon logisch. Hätte ja sein können daß da was integriert ist um, sagen wir mal, Blöcke zählen statt Datensätzen oder ein Counter je Tabelle mitgeführt welcher im Hintergrund aktualisiert wird.

[Dejan Vu]

Es wäre sinnvoll in *jedem* RDMBS einige kleine Optimierungen einzubauen.

Code:

select max(IndexSpalte1),min(IndexSpalte2), count(*) from ... <ohne where>

Diese drei Aggregatfunktionen könnten hochoptimiert ein Ergebnis liefern, solange in der Klausel keine Einschränkung angegeben ist. Ich finde es schade, das FB hier eine derartige Einschränkung hat. Aber selbst der SQL-Server ist zu blöd, bei einem Count(*) über eine Tabelle ohne WHERE in seiner Master-DB nachzuschauen. Bisher muss man sich in jedem RDMBS individuell einen abbrechen, um die Tabellengröße herauszubekommen. :wall:

Ach: Und soo selten sind diese Abfragen ja nu nich.

[Union]

Das kann allerdings beliebig komplex werden. Der Alias kann sich ja auch auf ein VIEW beziehen. Und falls es auch noch berechtigungsbasierte Sichtbarkeiten gibt, funktioniert das auch nicht mehr. Des weiteren müsste dieser Table-Recordcount ja auch noch in Transaktionen berücksichtigt werden. Trotzdem giebt es DB die das unterstützen, weil die Anzahl der Datensätze intern auch in den Metadaten gespeichert wird.

Dass der Index in Firebird allerdings nicht einfach "umgedreht" werden kann, empfinde ich schon als überflüssige Einschränkung (genau so wie auch die globale Sichrbarkeit von Indexnamen, aber das ist ein anderes Thema).

[Dejan Vu]

Zitat:

Zitat von Union (Beitrag 1257724)

Das kann allerdings beliebig komplex werden. Der Alias kann sich ja auch auf ein VIEW beziehen. Und falls es auch noch berechtigungsbasierte Sichtbarkeiten gibt, funktioniert das auch nicht mehr. Des weiteren müsste dieser Table-Recordcount ja auch noch in Transaktionen berücksichtigt werden. Trotzdem giebt es DB die das unterstützen, weil die Anzahl der Datensätze intern auch in den Metadaten gespeichert wird.

Profilabhängige Sichtbarkeit einzelner Records ist mir neu, es geht nur um Views und machbar ist das ja (wie man beim MAX sieht). Wieso beim Count(*) nicht?

Beim Optimieren geht es ja auch darum, bestimmte Sonderfälle optimiert auszuführen. Und die Anzahl der Datenstätze einer Tabelle sollte ein RDBMS schon kennen. Aber ist eh Wunschdenken, das das mal immer und überall schön schnell ist.

PS: Welches RDMBS optimiert das Count(*)?

[mkinzler]

Zitat:

Profilabhängige Sichtbarkeit einzelner Records ist mir neu

Es hängt aber vom Transaktionskontext ab.

[Union]

Zitat:

Zitat von Dejan Vu (Beitrag 1257726)

PS: Welches RDMBS optimiert das Count(*)?

z.B. ADS.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1257726)

Und die Anzahl der Datenstätze einer Tabelle sollte ein RDBMS schon kennen. Aber ist eh Wunschdenken

Tja, also in einer Single User DB ist das ja sehr übersichtlich. Aber auch da geht es schon los, je nach isolation level...
Wie lange läuft die Transaktion schon?
Wieviel/welche insert, (Update bei max/min), delete wurden innerhalb der Transaktion bereits gefahren?
Wieviele waren es vorher?
Ergibt zusammen?
Commit oder Rollback?

Dann im Mehrbenutzer System ..

Wünschen kann man sich natürlich viel, besonders wenn man für eine Software Geld bezahlt. Das ist aber bei FB nicht so.
Aber vielleicht nehmen die ja Spenden und kleine Wunschlisten .. ;)

[Dejan Vu]

[QUOTE=jobo;1257731Wünschen kann man sich natürlich viel, besonders wenn man für eine Software Geld bezahlt. Das ist aber bei FB nicht so.[/QUOTE]
Ich wünschte mir das nicht bei Firebird (weil open soße und eh nicht mein Tool) sondern bei den angeblich so perfekten teuren RDMBS. Und wenn ADS das kann... geht es also, egal ob mit oder ohne Transaktion oder wie auch immer. Wenn man 'select max(indexSpalte) from Tabelle' optimieren kann, dann ja wohl auch 'select count(*) from Tabelle'. Aber wir schweifen ab.

FB hat hier einen kleinen Schwachpunkt. Muss man wissen, dann krepelt man sich einen Extra-Index dafür und hat die Sache vergessen.

[tsteinmaurer]

Code:

Aber vielleicht nehmen die ja Spenden und kleine Wunschlisten ..

Die Firebird Foundation nimmt auch grosse Spenden und auch grosse Wunschlisten. Das SELECT COUNT(*) wirst du vermutlich aber trotzdem nicht schneller bekommen. ;-)

Mich würde interessieren, für was du ein COUNT(*) brauchst? Um zu überprüfen, ob eine Tabelle leer ist? Oder doch die exakte Anzahl? Oder darf es eine ungefähre Anzahl sein?