PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Was ist effizienter smallint oder character(10)?

Ich würde sagen, das Hinzufügen eines künstlichen smallint Primärschlüssel wäre billiger in Bezug auf Speicherplatz, wenn die Tabelle sorgfältig entworfen wird.

Ein smallint dauert 2 Bytes, während ein character(10) (was entgegen der Intuition eine varlena ist ), die ASCII-Zeichen enthält, verbraucht 14 Byte.

In der Tabelle wären die zusätzlichen 2 Bytes Verschwendung, aber vergessen Sie nicht, dass Sie einen Index für die Primärschlüsselspalte haben werden. Der indizierte Wert wird also tatsächlich zweimal gespeichert:einmal in der Tabelle, einmal im Index.

Lassen Sie uns der Einfachheit halber Tupel-Header und anderen Overhead ignorieren.

  • Die Verwendung der ISBN als Primärschlüssel kostet zusätzlich 14 Byte pro Tabellenzeile.

  • Hinzufügen eines smallint Der Primärschlüssel fügt zwei Bytes zur Tabelle und zwei zum Index hinzu, was insgesamt vier hinzugefügte Bytes ergibt.

Also Hinzufügen eines smallint Primärschlüssel sollte Platz sparen .

Sie sollten Ausrichtungsprobleme nicht ignorieren. Alle Datentypen werden an Speicheradressen gespeichert, die Vielfache bestimmter Zweierpotenzen sind. Dies wird von den Architekturen der Prozessoren verlangt. Ein smallint hat normalerweise Ausrichtung 2, character hat die Ausrichtung 1, während beispielsweise timestamp hat Ausrichtung 8.

Wenn Ihre Tabelle also definiert ist als

CREATE TABLE book (
   id smallint PRIMARY KEY,
   issue_time timestamp with time zone,
   isbn character(10)
);

Dann würden die Tabellendaten so aussehen:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 id    padding     issue_time

Die Zeile ist an einer 8-Byte-Grenze ausgerichtet, und die sechs Bytes vom Ende sind id bis zum Beginn von issue_time werden leere „Padding Bytes“.

Um das Beste daraus zu machen, müssen Sie also überlegen, in welcher Reihenfolge Sie die Spalten definieren.

Warum das alles in der Realität nicht sehr relevant ist:

Eine Tabelle mit 5000 oder 10000 Einträgen ist sowieso winzig.

Alles, was hier für die Optimierung des Speicherplatzes aufgewendet wird, ist bestenfalls unnötige Mikrooptimierung.

Doch was auf dem Planungstisch eine schlaue Idee sein mag, kann später leicht nach hinten losgehen:Wenn Sie – anders als erwartet – 70000 Bücher in dem Tisch unterbringen wollen, finden Sie dort eine smallint wird nicht ausreichen, selbst wenn Sie eine negative id zulassen s. Der Schmerz, den Sie ertragen müssen, wenn Sie den Datentyp eines Primärschlüssels und aller darauf referenzierenden Fremdschlüssel in einem Live-System ändern müssen, wird die Freude über die Einsparung von rund 100 KB durch clevere Optimierungen bei weitem überwiegen.