Обсуждение: Foreign key slows down copy/insert

I am new to cross references between tables, and I am trying to
understand how they impact performance. From reading the documentation I
was under the impression that deffering foreign keys would yield about
the same performance as dropping them before a copy, and adding them
after. However, I cannot see this in my test case.

I have a table A with an int column ID that references table B column
ID. Table B has about 150k rows, and has an index on B.ID. When trying
to copy 1 million rows into A, I get the following \timings:

1) drop FK, copy (200s), add FK (5s)
2) add FK defferable initially deffered, copy (I aborted after 30min)
3) add FK defferable initially deffered, begin, copy (200s), commit (I
aborted after 30min)

How do I explain why test cases 2 and 3 do not come close to case 1? Am
I missing something obvious?

Since the database I am working on has many FKs, I would rather not have
to drop/add them when I am loading large data sets.

If it would help I can write this out in a reproducable scenario. I am
using postgresql 7.4.5 at the moment.

Sincerely,

--
Richard van den Berg, CISSP
-------------------------------------------
Trust Factory B.V. |     www.dna-portal.net
Bazarstraat 44a    |  www.trust-factory.com
2518AK The Hague   |  Phone: +31 70 3620684
The Netherlands    |  Fax  : +31 70 3603009
-------------------------------------------

> Since the database I am working on has many FKs, I would rather not have to
> drop/add them when I am loading large data sets.

You may want to hunt the archives. IIRCC I saw a couple of posts in the
recent months about an update you can do to one of the system tables to disable
the key checks and then re-enable them after your done with the import.

Sincerely,

Joshua D. Drake
>

--
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
Reliable replication, Mammoth Replicator - http://www.commandprompt.com/

On Apr 14, 2005, at 7:59 AM, Richard van den Berg wrote:

> How do I explain why test cases 2 and 3 do not come close to case 1?
> Am I missing something obvious?

there's cost involved with enforcing the FK: if you're indexes can't be
used then you're doing a boatload of sequence scans to find and lock
the referenced rows in the parent tables.

Make sure you have indexes on your FK columns (on *both* tables), and
that the data type on both tables is the same.

Vivek Khera, Ph.D.
+1-301-869-4449 x806