Neues in der Kategorie PostgreSQL

Damit ich es nicht wieder vergesse (und beim nächsten mal die Suchmaschinen mit den falschen Suchbegriffen füttere):

Um den physikalischen Speicherplatz einer Datenbank, Tabelle, Indexes usw. zu berechnen stellt PostgreSQL einige Funktionen bereit: System Administration Functions.

Um zum Beispiel ergibt der folgende Query den auf der Festplatte belegten Speicher für die Tabelle sessions, inklusive Indexe, TOAST-Daten usw:  

db=> SELECT pg_total_relation_size('sessions');
 pg_total_relation_size 
------------------------
              563707904
(1 row)

Ohne total kann man sich auch nur den Speicherplatz für die Daten ohne Indexe und TOAST-Daten anzeigen lassen, ein Beispiel verkneife ich mir nun aber.

Und mit pg_size_pretty kann man sich das ganze auch menschenlesbar formatieren lassen:

SELECT pg_size_pretty(pg_total_relation_size('sessions'));
 pg_size_pretty 
----------------
 538 MB
(1 row)

Auch der von einem Index belegte Speicherplatz lässt sich so herausfinden: 

db=> SELECT pg_size_pretty(pg_total_relation_size('sessions_pkey'));
 pg_size_pretty 
----------------
 72 MB
(1 row)

Alles in allem ganz schön viel für ein paar gammelige Sessiondaten: Es wurden einfach zu viele angelegt, zum Beispiel an Stellen, an denen nur eventuell vorhandene ausgelesen werden sollten.

Man kann sich aber auch ausgeben lassen, wieviel Speicher eine Spalte benötigt. Hier sieht man dann auch gut, welchen Effekt die Kompression von langen Texten bei Postgres hat:

odem=> SELECT uri, length(text), pg_column_size(text) FROM main_data;
                     uri                     | length | pg_column_size 
---------------------------------------------+--------+----------------
 /insert_coin/medien/boese.html              |  17964 |          10324
 /insert_coin/medien/schluesse.html          |  23644 |          13588
 /insert_coin/experiment/protokoll.html      |   8331 |           5070
 /insert_coin/experiment/manipulationen.html |  23079 |          12601
 /insert_coin/vorwort.html                   |   2841 |           2841
 /insert_coin/experiment/aenderung.html      |   6107 |           3620
 /insert_coin/medien/at-bombe.html           |  28267 |          15941
 /insert_coin/impressum.html                 |    590 |            594

 [...]
 

Weitere Funktionen sind in der Postrgres-Dokumentation aufgeführt, zum Beispiel zum Berechnen des Gesamtspeicherverbrauchs einer Datenbank.

(dank an #postgresql-de (IRC) und ads)

Vor ein paar Tagen wurde eine neue Version des DBI-Treibers für PostgreSQL freigegeben: 2.1.3 ist die aktuelle DBD::Pg-Version auf dem CPAN.

Im Vergleich zur Version sind laut Changelog nur ein paar Kleinigkeiten dazu gekommen. 2.0 kam vor rund zwei Wochen und bringt einige neue Features mit:

• Echte Unterstützung für Arrays in PostgreSQL
• Unterstützung für asynchrone Queries
• Anpassungen an neuere Postgres-Versionen und Unterstützung neuer Features
• Diverse Bugfixes

Insbesondere die Unterstützung für Arrays sowie für asynchrone Queries finde ich sehr interessant.

Mit der Array-Unterstützung ist es nun möglich, beim schreibenden Queries auf ein Array-Feld einfach eine Array-Referenz zu übergeben und direkt an die Datenbank weiterzuleiten ohne dieses manuell in einen String zu wandeln. Umgekehrt erhält man auf Perl-Seite beim Lesen eine Array-Referenz anstatt eines flachen Strings.

Mit asynchronen Queries ist es möglich, weiter Perl-Code auszuführen während ein SQL-Query läuft. Damit kann dann nicht nur parallel weitergerechnet werden, der Query kann zur Laufzeit bei Bedarf auch abgebrochen werden. Das ist natürlich insbesondere bei mehreren Prozessoren oder Kernen interessant: Während der eine Kern die nächsten Daten aus der Datenbank holt, kann der andere die letzten Daten aufbereiten. In der DBD-Pg-Dokumentation sind ein paar praktische Beispiele enthalten.

Wer bisher noch kein PostgreSQL einsetzt sollte es sich mal anschauen. Mit der aktuellen Version 8.3 kamen nochmals sehr viele Features hinzu, PostgreSQL ist standardkonform, sicher, kann weit mehr als das häufig eingesetzte MySQL und ist sehr schnell. Bei einem (einfachen) Performance-Test (siehe Seite 19ff) vor rund einem Jahr war es selbst bei sehr einfachen Queries rund 50% schneller als MySQL. Bei Gelegenheit werde ich mal messen, wie sich DBD::Pg 2 gegenüber 1.49 verhält …