Re: Adding foreign key constraints without integrity check?

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: louis gonzales <gonzales(at)linuxlouis(dot)net>
Cc: Wes <wespvp(at)syntegra(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Adding foreign key constraints without integrity check?
Date: 2006-06-20 10:07:54
Message-ID: 4497C8FA.8060409@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

louis gonzales wrote:
> Florian,
> I understand where you're coming from. Indexes are always unique and
> all RDBMS systems use them to 'uniquely' identify a row from the the
> perspective of internal software management.
Surely there are non-unique indices - meaning indices for which there
are more then one entry for a given key.

> Index != PrimaryKey, so
> every table created, despite any Primary/Foreign key contraints put on
> them, always have a 1-1 Index per row entry. At least that's the way I
> understand it, can someone else affirm this statement or redirect a
> misguided 'me ;)'?

In postgresql at least, I believe that if you create no index (or pk), then
there is no index. The only exception are toast-tables, but you don't even
see those tables normally, and they're just an implementation detail of how
large attributes are stored.

However, the whole point of this thread was whether there is a way to create
a FK without postgres checking if it's actually satisfied, or not. This could
speed up restoring a dump, because you know that the FK is actually satisfied in
that case.

My suggestion was to create the fk _before_ loading the data, and disable it
similarly to what "--disable-triggers" doest. It turned out, however, that a
FK always depends on a unique index (be it a primary key, or not), which prevents
my plan from working :-(

greetings, Florian Pflug

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Szymic1 2006-06-20 11:22:40 Re: Why my cursor construction is so slow?
Previous Message simon 2006-06-20 10:06:24 merge result sets