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:35:00 |
Message-ID: | 425E7F94.4080602@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>> Deferring makes no difference to FK checking speed...
>
>
> But why then is the speed acceptable if I copy and then manually add the
> FK? Is the check done by the FK so much different from when it is done
> automatically using an active deffered FK?
Yeah I think it uses a different query formulation... Actually I only
assume that deferred fk's don't use that - I guess your experiment
proves that.
>> Well, that's what people do - even pg_dump will restore data and add
>> the foreign key afterward...
>
> If I have to go this route, is there a way of automatically dropping and
> re-adding FKs? I can probably query pg_constraints and drop the
> appropriate ones, but how do I re-add them after the copy/insert?
Actually, you can just "disable" them if you want to be really dirty :)
You have to be confident that the data you're inserting does satisfy
the FK, however otherwise you can end up with invalid data.
To see how to do that, try pg_dump with --disable-triggers mode enabled.
Just do a data-only dump.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-14 14:44:14 | Re: How to improve db performance with $7K? |
Previous Message | Richard van den Berg | 2005-04-14 14:26:30 | Re: Foreign key slows down copy/insert |