[FB 2.1] Schnelle Alternative zu Count(*) ?

[dataspider]

Hallo,

ich wollte der Vollständigkeit halber doch noch mal meine Tesergebnisse zu count zusammenfassen.
Ich wollte es einfach wissen.
Es war etwas kompliziert, da der erste Aufruf immer am längsten dauert. Dann greift der DB Cache.
Für eine zweiten Versuch müsste man den Rechner neu starten, da auch nach ShutDown und Neustart des Servers
die Abfragen schneller gehn. Wahrscheinlich greift hier der System Cache vom OS.

Die Ausführungsgeschwindigkeit für

1. select count(*)
2. select count(pk)
3. select count(pk) where pk > 0

ist in etwa gleich.
Tabelle hatte ca. 750.000 Datensätze.

Test 1 und 2 lag zwischen 500 un 540 ms.
test 3 lag etwa bei 620 ms.

Ich habe das ganze 30 mal durchgeführt.

So, wie es aussieht, verlangsamt die zusätzliche Verwendung des Indexes (Test 3) den Prozess sogar noch.


Frank

[mschaefer]

Zitat:

Zitat von alzaimar

Dann doch lieber die geheimen Metatabellen zugänglich machen.
Irgendwo muss doch einfach stehen, wieviel Records in dieser
Tabelle stehen. Ob nun mit oder ohne PK. Dammich, verdammt

Wenn das DBMS dies führen würde, dann wäre wohl auch das Count schneler.
Würde einem DBMS-Optimierer jedenfalls zutrauaen, dass er selbst auf die
geheimen Tabellen zugreifen würde, wenn da Zahlen geführt würden.

Grüße // Martin

[hoika]

Hallo,

wie schon weiter oben gesagt wurde,
läuft das Count(*) immer innerhalb einer Transaktion.
Durch die MGA von Firebird gibt es keine "feste Recordzahl".

Inwieweit man dem Nutzer sagen will 751.345, 751.346 ... Einträge sind drin,
steht zur Frage.


Heiko

[Elvis]

Zitat:

Zitat von hoika

wie schon weiter oben gesagt wurde,
läuft das Count(*) immer innerhalb einer Transaktion.
Durch die MGA von Firebird gibt es keine "feste Recordzahl".

Das gibt es in keinem DBMS, MGA oder nicht.

Auf der oben verlinkten FB Page wurde da schon auf sehr verzweifelte Hacks zurückgegriffen, also wird FB hier wohl nix bieten.

Die Frage ist halt, ob Trigger für jedes Delete und Insert auf Row-Ebene vertetbar wären.
Dann könnte sich Alzaimar selbst eine Meta table führen, in der zu jeder Tabelle die Records in der aktuellen Transaktion stehen.
Ob es dadurch zu mehr Deadlocks kommt bezweifle ich, schließlich schreibt man da ja nur, wenn man eh schon schreibt (insert/delete).

Trotzdem ganz schön bitter, IMO...

[alzaimar]

Zitat:

Zitat von mschaefer

Wenn das DBMS dies führen würde, dann wäre wohl auch das Count schneller. Würde einem DBMS-Optimierer jedenfalls zutrauen, dass er selbst auf die geheimen Tabellen zugreifen würde, wenn da Zahlen geführt würden.

Selbst MSSQL macht es nicht. Dort greift man die Metatabellen ab:

SQL-Code:

SELECT rows FROM sysindexes WHERE id = OBJECT_ID('table_name') AND indid < 2

Der Optimizer, der sich sonst einen Wolf optimiert (Hä? Wie? 'Der mit dem Wolf optimiert?' :gruebel: ), erspart sich das, vermutlich aus den von mir genannten Gründen.

Ich verstehe die Argumentation mit MGA nicht. Genauso, wie MGA mir eine (meine) Sicht auf alle Daten liefert, könnte das doch genauso mit der Zeilenanzahl funktionieren. Schließlich gibt es Tabellen für Tabellen, Felder, Views usw. Wieso steht in der Tabellentabelle nicht auch die Tabellengröße drin? Ich kapiere es nicht.

[mkinzler]

Wegen der Versionierung wären dann auch mehrere Metadatenversionen von Nöten

[mjustin]

Zitat:

Zitat von Elvis

Ob es dadurch zu mehr Deadlocks kommt bezweifle ich, schließlich schreibt man da ja nur, wenn man eh schon schreibt (insert/delete).

Wenn zwei Clients gleichzeitig einen neuen Satz in der gleichen Tabelle einfügen, und der Insert-Trigger dann die Satzzahl in der Satzzahl-Hilfstabelle um eins erhöhen will, dann sind das zwar zwei getrennte Inserts (daher natürlich auch kein Deadlockrisiko), aber dennoch zwei konkurrierende Updates auf einen Satz der Hilfstabelle. (Es sei denn, die Hilfstabelle enthält für jede *Transaktion* einen Satz.)

Es kommt zwar nicht zu einem Deadlock, aber sobald zwei Insert-Trigger gleichzeitig die alte Satzzahl lesen, und der erste Trigger diese Zahl (erhöht ums eins) erfolgreich zurückschreibt und committed, kann der zweite Insert Trigger den ursprünglichen Satz nicht mehr updaten (da er sich dadurch verändert hat), und muss aufgeben...

[mkinzler]

Da die Trigger in Transkationen laufen, sehe ich das Problem nicht. Allerdings wäre diese tabelle dann auch "versioniert" (mehrere konkurrierende Zugriffe -> mehrere Datensätze/Werte)

[alzaimar]

Ich hatte aber Deadlocks, und zwar immer beim Programmstart. Heute war ich out of office, aber morgen gehts der Deadlocke an den Sack. Meine Lösung besteht aus einer Tabelle mit einer Zeile und einem Feld ('RowSize') sowie zwei Triggern (BeforeInsert, BeforeDelete). Am Anfang der SW kommt manchmal genau 1x ein Deadlock. Danach nicht nochmal.

[hoika]

Hallo,

was passiert, wenn nach dem Insert ein Rollback gemacht wird ? ?
Dann wird natürlich kein OnDelete-Trigger aufgerufen.


Heiko