(PG/Java/Jdbc) Performantes ermitteln der Resultset größe

Hallo allerseits,

bietet der Postgres über seinen jdbc-Treiber eine elegante und performante Methode, die größe eines ResultSets zu ermitteln (Anzahl der Zeilen)? Oder bleibt da nur der üble Weg noch ein select count(… abzusetzen?

Man koennte ja auch den Cursor auf die letzte Reihe moven und die Row-Number nehmen. Ich bin mir nur noch nicht ganz sicher ob der Treiber dann erstmal alle Reihen fetcht oder ob er das sowieso schon vorher gemacht hat - was ja heute leider bei so ziemlich allen Jdbc-Treibern der Fall sein dürfte und eigentlich unnötig ist.

any idea ?

Gruß
Steffen

Unter “wost case condition” ist die Anzahl der Zeilen einer Tabelle nicht konstant. Was nützt da ein Augenblickwert über die Anzahl der Zeilen einer Tabelle, der schon im nächstem Moment schon wieder ungültig sein kann?



mfg

fristo

Wird so selten einfach mal auf eine Frage geantwortet, und stattdessen ueber Sinn bzw. Unsinn einer Problemstellung debattiert :slight_smile:

Weil Du es bist

  1. Mehr Pragmatismus bitte
  2. Mehr Usability bitte
  3. Zum Thema:

Da die meisten DB’s bei einer Query ohnehin jeden Datensatz “anfassen” wenn gefiltert gejoint oder was auch immer wird - waere es doch ein einfaches für diese, mir genau fuer diesen Snapshot (Resultset) mitzuteilen, wieviel Datensaetze/Tupel dieses Resultset “beinhaltet”. Es ist unerheblich ob das im naechsten Augenblick nicht mehr der “Wirklichkeit” in dieser DB entspricht - OBWOHL es unter gewissen Vorraussetzungen (geeignete Transaktionsisolation) für die Query noch irgendwie stimmt.

Wenn es also einen Weg gäbe, diese atomar (wärend der Erzeugung des Resultsets) ermittelte Information (Anzahl) irgendwie elegant abzugreifen, warum soll man diese dann nicht auch für geeignete Zwecke nutzen?

Also hast du Ideen ? Oder doch nur Zweifel :wink:

Gruß & Dank
Steffen

Hast du dich schon mal mit ISAM, Trees etc befasst? Also das eine DB jeden Datensatz anfasst halt ich für ein Gerücht. Wenn es das machen würde, müsste ich mir nen neuen Job suchen da die Datenmenge mit denen ich handiere etwas größer ist. :wink:

cu tb.

Hi symbiont,

ich versuch’s mal etwas Praxis-bezogener, wobei ich nicht weiß, ob es tatsächlich hilft, weil es erstmal nix mit dem JDBC-Treiber zu tun hat.

Falls du deine entsprechende(n) Abfrage(n) in eine PL/pgSQL-Funktion packst, hast Du die Möglichkeit, nach dem Ausführen eines dynamischen Queries mit EXECUTE, den sog. RESULT STATUS mit GET DIAGNOSTICS abzufragen. Da kriegt man auch die Anzahl der durch den Query betroffenen Zeilen.

Damit kriegt man auch die RESULT_OID, die man evt. mit einer geeigneten System Information Function auswerten könnte (was sich aber vermutlich nicht von einem SELECT count(…)… unterscheiden würde… :frowning: )

CU
Fröstel

Nicht alles, was Du nicht gleich verstehst, muß deswegen schlecht sein. Okay? Es geht um die Größe des ResultSets, und die ist, in Abhängigkeit des Clients, durchaus abfragbar. Die ändert sich auch nicht innerhalb einer TX. Das, was Fröstel da sagte, ist offensichtlich hilfreicher, ich wollt schon ähnlich antworten, weiß aber nicht, ob das via JDBC funktioniert. Du hast hier IIRC schon Fragen in dieser Richtung inhaltsvoller beantwortet, warum nicht diese?

Andreas

Für Dich und weil Du es bist:

Das hier ist ein für Dich kostenfreies Forum, wo Leute mit möglicherweise mehr Peilung als Du Dir antworten - und Dir auch mal Gegenfragen stellen. Akzeptiere das als ihr gutes Recht, okay?

Andreas

gut das es öffentlich ist, dennoch muss mir ja nicht alles genehm sein - und ich denke auch nicht, dass ich allzu aggressiv darauf hingewiesen habe …

Zum Thema:

der Hinweis von Fröstel koennte tatsächlich weiterhelfen - auch wenn ich noch nicht sehe wie ich von einem Client aus (z.B jdbc) diese DIAGNOSTICS information abgreifen kann. So wie es ausschaut endet dessen Gültigkeitsbereich am Ende einer Stored-Procedure

… hmm …

Steffen

also dieses GET DIAGNOSTICS scheint tatsaechlich nur innerhalb einer stored procedure zu funktionieren …

waere ich nun verrueckt(er) und wuerde das nutzen wollen, dann muesste ich tatsaechlich irgendwie eine Query zu einer SP an die DB schicken … da ausfuehren lassen und habe (mit etwas Glück) dann ROW_COUNT aber wie ich auf ein Resultset von hinter den Bergen zugreifen muesste - OMG - die Welt ist so schlecht :slight_smile:

da der Postgres Jdbc-Treiber im “normalbetrieb” ohnehin das gesammte Resultset nach der Abfrage fetcht sollte man sich nicht davor scheuen “rowcount” ueber ein ResultSet.last() -> ResultSet.row() zu ermitteln - natürlich unter Beachtung diverser Prüfungen - z.B ob das Resultset nicht leer ist etc.

Dieses Verhalten legen irgendwie alle Treiber an den Tag, die ich so kenne. Weil man wohl wie immer davon ausgeht, dass Ergebnismengen “klein” sind. tztz …

Groß will ich … GROSS !!! SCHNELLER WEITER HÖHER GRÖSSER

Hallo Symbiont,

Versuchs mal damit:

ResultSet rs = stmt.executeQuery(“SELECT a, b, c FROM TABLE2”);
ResultSetMetaData rsmd = rs.getMetaData();

int numberOfColumns = rsmd.getColumnCount();
boolean b = rsmd.isSearchable(1);

Alternativ unterstützt der Postgres Klasse 4 JDBC Treiber Version 8.x
auch noch Scrollable Resultsets (JDBC Standard API 2.0 Compliant)

Hier ein Beilspiel:
Java Standard: JDBC - Wikibooks

Es sei auch noch drauf hingewiesen, dass das JDBC 4.0 API
derzeit die gültige Referenz ist und daher lassen sich manche Dinge
schon durch das API und nocht unbedingt durch Treiber Mechanismen
besser lösen.

Zu den Treibern selber sei gesagt, dass es für die populären
Datenbanken oftmals mehr als nur einen Treiber gibt und dieser
daher austauschbar bleibt. Hier die SUN Liste über die verfügbaren
Thirdpartytreiber für Postgres um via Java auf Postgres zuzugreifen.
Browse All JDBC Drivers

Kleiner Tip für WebApplikationen mit JDBC/Postgres.
immer JNDI vorschalten und das geht am besten mit:
DBCP - Overview
Ist mittlerweile beim Tomcat Servletcontainer der Standard
um auf DB’s via JDBC zuzugreifen.

Es ging nicht um die Anzahl der Spalten, sondern um die Anzahl der Tupels - also die Größe des Resultsets …