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

Wow, vielen Dank. Es ist der Index der so viel Platz braucht (1238974464 Bytes) und du hattest recht die Tabelle hat natürlich einen Primärschlüssel, wobei ich den gleich wohl entfernen werde.
Muss ich dann OIDS einschalten, oder ist es ok, wenn eine Tabelle keinen Primärschlüssel hat?
\d Tabelle zeigt mir übrigens dieses an:
Tabelle »value_stores.tbl_vs_float«
Spalte | Typ | Attribute
------------------------------------+-----------------------------+----------------------------------------------------------------------------
id | bigint | not null Vorgabewert nextval('value_stores.tbl_vs_float_id_seq'::regclass)
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 | not null Vorgabewert now()
ts_end | timestamp without time zone |
Indexe:
"tbl_vs_float_pk" PRIMARY KEY, btree (id) WITH (fillfactor=10)
Check-Constraints:
"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))
Fremdschlüssel-Constraints:
"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
"tbl_vs_float_fk_tbl_devices" FOREIGN KEY (tbl_device_id) REFERENCES devicemanager.tbl_devices(id) MATCH FULL ON UPDATE CASCADE ON DELETE CASCADE
"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

Lars

-----Ursprüngliche Nachricht-----
Von: Nicolas Barbier [mailto:nicolas(dot)barbier(at)gmail(dot)com]
Gesendet: Mittwoch, 3. April 2013 23:41
An: Lars Grundei
Cc: pgsql-de-allgemein(at)postgresql(dot)org
Betreff: Re: [pgsql-de-allgemein] Datenbankgröße unplausibel

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

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?