PostgreSQL maakt automatisch indexen op primaire sleutels en unieke beperkingen, maar niet aan de verwijzende kant van relaties met externe sleutels.
Wanneer Pg een impliciete index aanmaakt, zal het een NOTICE . uitzenden -niveau bericht dat u kunt zien in psql en/of de systeemlogboeken, zodat u kunt zien wanneer het gebeurt. Automatisch aangemaakte indexen zijn zichtbaar in \d output ook voor een tafel.
De documentatie over unieke indexen zegt:
PostgreSQL maakt automatisch een index voor elke unieke beperking en primaire sleutelbeperking om uniciteit af te dwingen. Het is dus niet nodig om expliciet een index te maken voor kolommen met primaire sleutels.
en de documentatie over beperkingen zegt:
Aangezien voor het VERWIJDEREN van een rij uit de tabel waarnaar wordt verwezen of een UPDATE van de kolom waarnaar wordt verwezen, een scan van de rijen van de referentietabel nodig is die overeenkomt met de oude waarde, is het vaak een goed idee om de kolommen waarnaar wordt verwezen te indexeren. Omdat dit niet altijd nodig is, en er veel keuzes beschikbaar zijn over hoe te indexeren, wordt bij de declaratie van een externe sleutelbeperking niet automatisch een index gemaakt op de verwijzende kolommen.
Daarom moet u zelf indexen op externe sleutels maken als u ze wilt.
Merk op dat als je primaire-buitenlandse sleutels gebruikt, zoals 2 FK's als een PK in een M-naar-N-tabel, je een index op de PK hebt en waarschijnlijk geen extra indexen hoeft te maken.
Hoewel het meestal een goed idee is om een index te maken op (of op te nemen) van uw referencing-side refererende sleutelkolommen, is dit niet vereist. Elke index die u toevoegt, vertraagt DML-bewerkingen enigszins, dus u betaalt prestatiekosten voor elke INSERT , UPDATE of DELETE . Als de index zelden wordt gebruikt, is het misschien niet de moeite waard om te hebben.