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

Der Füllfaktor ist wohl "schlecht" gewählt worden (ehrlich gesagt war mir das damals nicht bewusst, die DB habe ich mit pgModeler erstellt und da ist es der Standardwert).
Wie auch immer, ich habe das entsprechend korrigiert, die Tabellen haben nun alle einen Füllfaktor von 95, bei den Wertspeichern habe ich den auf 100 gestellt, denn die Annahme das nur Daten dazu kommen stimmt.

Die Größe beläuft sich nun auf 610MB :-), nochmal herzlichen Dank für die schnelle und kompetente Hilfe.

Lars

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

Am 4. April 2013 10:51 schrieb Lars Grundei <l(dot)grundei(at)meteocontrol(dot)de>:

> 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?

Oids sind auch dann nicht nötig. Ich glaube aber, dass du ein anderes Problem hast:

> "tbl_vs_float_pk" PRIMARY KEY, btree (id) WITH (fillfactor=10)

„fillfactor=10“ bedeutet, dass nur 10% von jedem Index-Leaf-Block benutzt wird (Default ist 90%). fillfactor zu nahe an 100% stellen ist typischerweise auch gefährlich: INSERTs und UPDATEs „in der Mitte“ werden in diesem Fall mehr Arbeit machen müssen und alle geänderte (einst 100%-gefüllte) Blocks nur 50% voll machen. Weil ich unterstelle, dass du nur am Ende INSERTst, und nie UPDATEst (?), ist 100% wahrscheinlich OK in deinem Fall.

<URL:http://www.postgresql.org/docs/current/static/sql-createindex.html>

Nicolas

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