Es ist immer ein gutes Ideal, Spalten davon abzuhalten, NULL zu sein, wenn Sie es vermeiden können, weil die Semantik der Verwendung so unordentlich ist; siehe Was ist der Deal mit NULLs? für eine gute Diskussion darüber, wie diese Sie in Schwierigkeiten bringen können.
In Versionen von PostgreSQL bis zu 8.2 wusste die Software nicht, wie man Vergleiche für den häufigsten Typindex (den B-Baum) so durchführt, dass darin NULL-Werte gefunden werden. Im entsprechenden Teil der Dokumentation zu den Indextypen sehen Sie, dass dies als "aber" beschrieben wird Beachten Sie, dass IS NULL nicht äquivalent zu = ist und nicht indexierbar ist. Der effektive Nachteil besteht darin, dass der Planer, wenn Sie eine Abfrage angeben, die NULL-Werte enthalten muss, diese unter Verwendung des offensichtlichen Index für diesen Fall möglicherweise nicht erfüllen kann. Als einfaches Beispiel, wenn Sie eine ORDER BY-Anweisung haben, die mit einem Index beschleunigt werden könnte, aber Ihre Abfrage auch NULL-Werte zurückgeben muss, kann der Optimierer diesen Index nicht verwenden, da das Ergebnis keine NULL-Daten enthält - und daher unvollständig und nutzlos sein. Der Optimierer weiß dies und führt stattdessen einen nicht indizierten Scan der Tabelle durch, was sehr teuer sein kann.
PostgreSQL verbesserte dies in 8.3 , "eine IS NULL-Bedingung für eine Indexspalte kann mit einem B-Tree-Index verwendet werden ". Die Situationen, in denen Sie gebrannt werden können, indem Sie versuchen, etwas mit NULL-Werten zu indizieren, wurden reduziert. Da die NULL-Semantik jedoch immer noch sehr schmerzhaft ist und Sie möglicherweise in eine Situation geraten, in der selbst der 8.3-Planer nicht das tut, was Sie von ihm erwarten, sollten Sie nach Möglichkeit NOT NULL verwenden, um Ihre Chancen auf eine schlecht optimierte Abfrage zu verringern .
Die Einstellung von NOT NULL hat keine Auswirkung auf die Leistung. Ein paar Zyklen für die Überprüfung - irrelevant.
Aber Sie können die Leistung verbessern, indem Sie NULL anstelle von Dummy-Werten verwenden. Je nach Datentypen können Sie viel Speicherplatz und RAM sparen und dadurch alles beschleunigen.
Die Null-Bitmap wird nur zugewiesen, wenn NULL-Werte in der Zeile vorhanden sind. Es ist ein Bit für jede Spalte in der Zeile (NULL oder nicht). Bei Tabellen mit bis zu 8 Spalten ist die Null-Bitmap praktisch vollständig frei, wobei ein Ersatzbyte zwischen Tupel-Header und Zeilendaten verwendet wird. Danach wird der Speicherplatz in Vielfachen von MAXALIGN (typischerweise 8 Bytes, die 64 Spalten abdecken) zugewiesen. Der Unterschied ist zum Padding verloren. Sie bezahlen also den vollen (niedrigen!) Preis für den ersten NULL-Wert in jeder Zeile . Zusätzliche NULL-Werte können nur Platz sparen.
Die minimale Speicheranforderung für einen Nicht-Null-Wert ist 1 Byte ( boolean , "char" , ...) oder typischerweise viel mehr plus (möglicherweise) Auffüllung für die Ausrichtung. Lesen Sie die Datentypen oder überprüfen Sie die Details in der Systemtabelle pg_type .
Mehr über den Null-Speicher:
Nein, solange Sie NULLs nicht wirklich in der Tabelle speichern, sehen die Indizes genau gleich aus (und ebenso effizient).
Das Setzen der Spalte auf NOT NULL hat jedoch viele andere Vorteile, daher sollten Sie immer darauf setzen, wenn Sie keine NULL-Werte darin speichern wollen: -)
Tags und Links postgresql performance database-design null