Ich versuche nicht, die Debatte UUID gegen serielle Ganzzahlschlüssel neu zu starten. Ich weiß, dass es für beide Seiten gültige Punkte gibt. Ich verwende UUIDs als Primärschlüssel in mehreren meiner Tabellen.

Spaltentyp:"uuidKey" text NOT NULLIndex:CREATE UNIQUE INDEX grand_pkey ON grand USING btree ("uuidKey")Primary Key Constraint:ADD CONSTRAINT grand_pkey PRIMARY KEY ("uuidKey");

Hier ist meine erste Frage; Gibt es in PostgreSQL 9.4 einen Leistungsvorteil, wenn der Spaltentyp auf UUID gesetzt wird?

Die Dokumentationhttp: //www.postgresql.org/docs/9.4/static/datatype-uuid.htm beschreibt die UUIDs, aber gibt es außer der Typensicherheit noch weitere Vorteile für die Verwendung dieses Typs anstelle vontext Art? In der Dokumentation der Zeichentypen wird angezeigt, dasschar(n) hätte keinen Vorteil gegenübertext in PostgreSQL.

Tipp: Es gibt keinen Leistungsunterschied zwischen diesen drei Typen, abgesehen von erhöhtem Speicherplatz bei Verwendung des mit Leerzeichen aufgefüllten Typs und ein paar zusätzlichen CPU-Zyklen zum Überprüfen der Länge beim Speichern in einer Spalte mit eingeschränkten Längen. Während Zeichen (n) in einigen anderen Datenbanksystemen Leistungsvorteile bietet, gibt es in PostgreSQL keinen solchen Vorteil. Tatsächlich ist das Zeichen (n) aufgrund seiner zusätzlichen Speicherkosten normalerweise das langsamste der drei Zeichen. In den meisten Situationen sollten stattdessen unterschiedliche Texte oder Zeichen verwendet werden.

Ich mache mir keine Sorgen um Speicherplatz. Ich frage mich nur, ob sich das Benchmarking von UUID- und Textspaltentypen lohnt.

Zweite Frage, Hash vs B-Tree-Indizes. Es hat keinen Sinn, UUID-Schlüssel zu sortieren. Hätte B-Tree also noch weitere Vorteile gegenüber dem Hash-Index?