Re: [pgsql-de-allgemein] Datenbankgröße unplausibel

Am 3. April 2013 19:18 schrieb Lars Grundei <l(dot)grundei(at)meteocontrol(dot)de>:

> ich habe hier eine Datenbank mit PostgreSQL 9.1 laufen. Was ich nicht
> verstehe ist der Speicherbedarf auf der Festplatte, der erscheint mit viel
> zu hoch.
> In der Datenbank werden hauptsächlich Messwerte gespeichert, die Tabelle zum
> Speichern der Werte ist so aufgebaut:
> CREATE TABLE tbl_vs_float (
> id bigint NOT NULL,
> tbl_device_id integer NOT NULL,
> tbl_driver_value_types_id integer,
> tbl_connection_type_value_types_id integer,
> val double precision,
> ts_start timestamp without time zone DEFAULT now() NOT NULL,
> ts_end timestamp without time zone,
> CONSTRAINT tbl_vs_float_check_fk CHECK ((((tbl_driver_value_types_id IS
> NOT NULL) OR (tbl_connection_type_value_types_id IS NOT NULL)) AND
> ((tbl_driver_value_types_id IS NULL) OR (tbl_connection_type_value_types_id
> IS NULL))))
> );
>
> Und hat diese Constraints:
> ALTER TABLE ONLY tbl_vs_float ADD CONSTRAINT
> tbl_vs_float_fk_tbl_connection_type_value_types FOREIGN KEY
> (tbl_connection_type_value_types_id) REFERENCES
> devicemanager.tbl_connection_type_value_types(id) MATCH FULL ON UPDATE
> CASCADE ON DELETE CASCADE;
> ALTER TABLE ONLY tbl_vs_float ADD CONSTRAINT tbl_vs_float_fk_tbl_devices
> FOREIGN KEY (tbl_device_id) REFERENCES devicemanager.tbl_devices(id) MATCH
> FULL ON UPDATE CASCADE ON DELETE CASCADE;
> ALTER TABLE ONLY tbl_vs_float ADD CONSTRAINT
> tbl_vs_float_fk_tbl_driver_value_types FOREIGN KEY
> (tbl_driver_value_types_id) REFERENCES
> devicemanager.tbl_driver_value_types(id) MATCH FULL ON UPDATE CASCADE ON
> DELETE CASCADE;

Da sehe ich keine Indexe (es gibt sogar keinen primary Key?), ist das
korrekt? Schau mal nach mit psql:

\d tbl_vs_float

Indexe sollten (wenn es welche gibt) gleich nach „Indexe:“ ganz unten
gezeigt werden. Auch interessant könnte sein:

SELECT pg_indexes_size('tbl_vs_float');
SELECT pg_relation_size('tbl_vs_float');
SELECT pg_total_relation_size('tbl_vs_float');

> Eine Zeile braucht also 52 Bytes für die Daten + X für die DB. Nun habe ich
> aktuell 6,2 Millionen Einträge in der Tabelle, und die DB braucht dafür 1,6
> GB. Das verstehe ich einfach nicht, denn das sind fast 300 Bytes pro Zeile,
> also quasi sechsfacher Overhead für die DB, das kann doch nicht sein, oder
> doch?

Für X, sehe:

<URL:http://stackoverflow.com/questions/13570613/making-sense-of-postgres-row-sizes>

(also X = 24 + ich unterstelle, dass in 52 das Padding nicht mitgerechnet ist?)

> Also habe ich mal ein bisschen gesucht, im Netz wird oft behauptet, dass es
> hilft, einen Dump zu machen, die DB zu löschen und mit dem Dump
> wiederherzustellen.

Das hilft nur wirklich, wenn man irgendwie ganz viel
Heap-Fragmentation verursacht hat (z. B., indem man ganz viele „dead
Rows“ viel zu lange nicht mit VACUUM entfernt hat) oder „bloated
Indexe“ hat. CLUSTER oder VACUUM FULL könnten in diesen Fällen auch
helfen ­– ist aber klar nicht dein jetztiges Problem.

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?