seq.-scan bei select count(*) ohne condition ?

warum ?

bzw. was kann ich tun, damit er sowas aus der statistik holt?

PG wird das nicht aus der Statistik holen bzw. wäre diese nur annähernd genau.

Du könntest jedoch mittels eines Triggers deine eigene Statistik schreiben.

mal so ganz bloed gefragt - unter welchen wahnwitzigen bedingungen koennte so ein zaehler mal nicht mehr “stimmen”, wenn ich bei after insert und after delete inc bzw decrementiere ?

Dein eigener Counter wird stimmen.

Mir ging es um die PG-internen Statistiken. Diese können durchaus mal abweichen.

Du hast eine table. Du hast Client A, der davon 10 Records löscht. Du hast Client B, der 20 neue einfügt. Du hast Client D, der 5 einfügt und 8 löscht. Du hast Client E, der 2 einfügt und 30 löscht. Du hast noch ein paar Clients mehr, die wirre Dinge tun. Alle machen dies in einer Transaktion. Ach nee, nicht alle. Einige machen ein COMMIT, andere ein ROLLBACK, andere pennen in ihrer TX. Du hast Client X+N, welcher wissen will, wie viele Datensätze es grad gibt. Nenne mir einen einfachen Weg, dies zu ermitteln, ohne die zu diesem Zeitpunkt für den Client X+N gültigen Records hart zu zählen, un dDu bist der Held des Tages.


Andreas

sollte det count doch immer “stimmen” ?! die trigger sind doch innerhalb der transaktion und wenn die nicht abgeschlossen ist (insert bzw. delete commited) bleibt der alte count den anderen erhalten - was ja auch stimmt …
hab ich was uebersehen ?

was ich sehr schade finde … select count … wird ja nun nicht sonderlich selten benötigt … mysql z.B. kennt immer “die anzahl” der “sicheren” tupels :wink:

Ja - wenn der Datensatz in einer Transaktion aktualisiert wird, blockiert der alle anderen Transaktionen, bis die erste Transaktion entweder committed oder zurückgerollt wird.


Das funktioniert nur mit MyISAM Tabellen. InnoDB muss auch losgehen und zählen, weil hier Transaktionen ins Spiel kommen.

Stimmt!

philosophier … wenn man aber von anfang an ein count haette - und dies irgendwie bei den transaktions-logs unterbringen und “pflegen” wuerde, dann koennte man das doch auch fuer transaktionsorientierte DB anbieten ?! also jeder transaktions-stand kennt den count bei BEGIN und zaehlt “seinen count” und wird zum “neuen count” bei COMMIT - oder eben nicht bei ROLLBACK ?!

[edit]
also mit beruecksichtigung des von anderen bereits COMMITeten counts natuerlich … freilich laeuft da semantisch gesehen einiges parallel - nur laesst sich sowas ja gut synchronisieren …

Nicht ganz. Dafür müsstest du ja Informationen, die in einer Transaktion sind, an andere melden. Ausserdem müsste trotzdem jede Transaktion lokal ihren Counter fahren - weil der könnte ja in dieser Transaktion anders sein als in allen anderen Transaktionen, die laufen und anders sein als im Rest der Datenbank.

So einfach, wie sich das anhört, ist das nicht.
Aber: du könntest diese Diskussion trotzdem mal auf der -hackers Mailingliste anstoßen, wenn du möchtest. Interessant wären die Argumente und Reaktionen schon …

ich mag immernoch nur philosophieren - keine sorge - das PG ist in ordnung :slight_smile:

Nicht ganz. (denke ich) … denn was ich in einer transaktion treibe geht andere TX nix an … bis zum commit der transaktion.

in meiner transaktion weiss ich zu jedem zeitpunkt wenn ich das select count absetze, wieviele tupes “von aussen” fuer mich sichtbar sind (commited von andern) und wieviele ich committed habe …

Man müsste also einfach diesen count (statistik-daten) in das TX-log mit aufnehmen - was wahrschienlich PG nicht macht.

vielleicht sieht man es aber auch nicht fuer notwendig, diesen speziellen fall (count ohne condition) zu optimieren - was schade ist - denn in einer gut streuenden datenmenge haette ich schnell nen count ueber alle tupels und wenn ich ne condition habe, dann auch schnell - da das resultset nicht sonderlich gross ist.

read uncommitted / dirty read - im klassischen sinn - scheint PG sowieso nicht zu unterstuetzen … was auch ok ist. man meint lt. doku, dass man das als read committed “behandelt” - was aber m.E. nicht das gleiche ist wie read uncommited - was solls.

ich habe mich da mal angemeldet … aber irgendwie hat das mit dem registrierungsverfahren nicht geklappt … hmm … und ausserdem bin ich wohl nicht so sehr mit meinem Herzblut bei PG wie ihr :slight_smile: DBs im allgemeinen find ich thematisch sehr interessant - ich suche aber gern nach loesungen die auf moeglichst vielen umsetzbar sind.

hier geht es im speziellen um das thema oberflaeche - also ein “virtuelles” Table widget - das on bei bedarf (virtuell) die tupels aus der DB fetcht - also immer nur die, die ich sehen kann. Das einzige was die Table aber wissen sollte waere die Anzahl der verfuegbaren Tupel. Was ich vermeiden will, ist ans ende des Resultset zu huepfen - dann faengt er an zu fetchen und der effekt (schnelle anzeige) wäre futsch - daher select count - die paar millisekunden - so dachte ich :slight_smile: - machens kraut auch nicht fett - und die moeglichkeit, dass da mal paar leere zu sehen sind oder paar zu wenig übersehe ich grosszuegig - man kann ansichten ja aktualisieren wenn man zweifel hat :slight_smile: - das kann man auch gut abfangen indem man die groesse der Tabelle mal eben anpasst, wenn das tatsaechliche Resultset dann doch weniger zeilen liefert - oder vergroeßern. So eine step-by-step loesung hatte ch auch schonmal - aber sieht irgednwie scheisse aus, wenn der scrollbalken andauernd meint “aetsch da ist doch noch nicht das ende - reingelegt” und sich automatisch erweitert - so in 1000er schritten. Also wenn ich “ungefähr” die anzahl haette wäre ich zufrieden.

Ich glaube zu wissen, dass das 3er Protokoll von PG die Anzahl der gefundenen Tupel des Resultset sowieso kennt - das API hat dafuer ne Fkt. - aber die Info ist ueber JDBC nicht verfuegbar - und wenn, dann nicht JDBC standard. Das waere natuerlich das allerfeinste.