Datenbankgröße unplausibel

From: Lars Grundei <l(dot)grundei(at)meteocontrol(dot)de>
To: "pgsql-de-allgemein(at)postgresql(dot)org" <pgsql-de-allgemein(at)postgresql(dot)org>
Subject: Datenbankgröße unplausibel
Date: 2013-04-03 17:18:36
Message-ID: 0EAF4A34C2A33B4FB958F0A6150072AC3657B6608E@mcsrv03.meteocontrol.intra
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Hallo Zusammen,

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;

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?

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. Also habe ich das gemacht. Hilft nur leider nicht, der
Dump (als SQL) ist "gerade mal" 550 MB groß (dachte schon, alles wird gut),
nach dem Einspielen belegt die DB aber wieder 1,6 GB.

Ich weiß leider nicht, was ich noch tun kann, aber der Overhead ist
einfachmal zu groß, bin daher für jeden Tipp dankbar.

Viele Grüße
Lars

PS: Hier mal ein kurzer Ausschnitt aus dem Dump nur für alle Fälle.

COPY tbl_vs_float (id, tbl_device_id, tbl_driver_value_types_id,
tbl_connection_type_value_types_id, val, ts_start, ts_end) FROM stdin;
1 1 1 \N 2893.73773200000005 2013-03-22
12:36:24.362992 2013-03-22 12:36:24.328199
2 1 2 \N 338.584743000000003 2013-03-22
12:36:24.362992 2013-03-22 12:36:24.328199
...
6179352 1 3 \N 4333.81734099999994 2013-04-02
10:01:30.062868 2013-04-02 10:01:30.44396
\.

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Andreas Kretschmer 2013-04-03 17:47:30 Re: Datenbankgröße unplausibel
Previous Message Andreas Kretschmer 2013-03-30 07:36:46 Re: FOR-LOOP durch eine Ergebnismenge