Re: Speicherverbrauch / c't Datenbank-Contest

Alvar Freude writes:

> leider komme ich erst jetzt zu den Letzten Zügen ;) beim c't
> Datenbank-Contest; für die mittelgroße Datenbank dürften auch
> Kleinigkeiten im Speicherverbrauch interessant sein, daher frage ich
> mich, ob ich die "customers"-Tabelle in zwei aufteile: eine, in die die
> Daten geschrieben werden, und eine Login-Tabelle, auf die im sonstigen
> verlauf zugegriffen wird.

Aus Sicht des relationalen Entwurfs ein klares "das ist böse", aus
Sicht der Optimierung ein klares "könnte was bringen" :-).

> Die customers-Tabelle hat im Falle der mittelgroßen Datenbank 2
> Millionen Zeilen. Beim Login und via Foreign Keys beim Bestellen wird
> darauf zugegriffen.

Speziell bei foreign Keys spielt die Tupelgröße keine Rolle, da dazu
nur ein Indexzugriff nötig ist, und Indexe getrennt von den Daten und
anderen Indexen gehalten werden.

> Postgres lädt immer die ganze Zeile, oder wird das spaltenweise abgelegt
> (und reingeladen)?

Depends. Bei deiner customers-Tabelle würde ich ersteres sagen;
Getoastete Typen können jedoch auch Out-Of-Band gehalten werden.

> Weiß gerade jemand Zahlen, wieviel das hier pro Zeile braucht, wenn in
> den Varchar-Feldern zwischen 6 und 20 Bytes stehen? Oder gibt es
> vielleicht einen Query über den Systemkatalog, mit dem man den
> Speicherverbrauch einer Zeile (oder einer Tabelle) errechnen kann? Ich
> bin etwas spät, sonst würde ich es einfach ausprobieren ;)

Du kannst Daten oder auch ganze Records durch die passende
length(foo_send()) jagen. Das müßte dann genau dem entsprechen, was
auf der Platte landet minus Seitenheader.

Beispiel:

--8<---------------cut here---------------start------------->8---
scratch=# select *, length(record_send(foo)) from foo;
bar | length
--------------------------------------------------+--------
foo | 15
foo bar | 19
foo bar bazzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz | 60
(3 rows)

scratch=#
--8<---------------cut here---------------end--------------->8---

HTH
Andreas