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

From: Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>
To: Lars Grundei <l(dot)grundei(at)meteocontrol(dot)de>
Cc: "pgsql-de-allgemein(at)postgresql(dot)org" <pgsql-de-allgemein(at)postgresql(dot)org>
Subject: Re: [pgsql-de-allgemein] AW: [pgsql-de-allgemein] Datenbankgröße unplausibel
Date: 2013-04-04 09:34:33
Message-ID: CAP-rdTbfus7rv3+LHj=3V3Xsw6JY2otPPtPkofGJHPdBq-YTqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

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?

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Hans-Jürgen Schönig 2013-04-04 10:28:33 Re: [pgsql-de-allgemein] Datenbankgröße unplausibel
Previous Message Lars Grundei 2013-04-04 08:51:52 AW: [pgsql-de-allgemein] Datenbankgröße unplausibel