From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Richard van den Berg <richard(dot)vandenberg(at)trust-factory(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Foreign key slows down copy/insert |
Date: | 2005-04-14 14:07:39 |
Message-ID: | 425E792B.4020500@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> 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.
Even if you defer them, it just defers the check, doesn't eliminate it...
> 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?
Deferring makes no difference to FK checking speed...
> 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.
Well, that's what people do - even pg_dump will restore data and add the
foreign key afterward...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Dawid Kuroczko | 2005-04-14 14:20:36 | Re: speed of querry? |
Previous Message | Christopher Kings-Lynne | 2005-04-14 14:04:24 | Re: Use of data within indexes |