Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 462252E0033 for ; Thu, 5 Jun 2008 04:19:41 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 12047-09 for ; Thu, 5 Jun 2008 04:19:35 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by developer.postgresql.org (Postfix) with ESMTP id C1C8C2E0035 for ; Thu, 5 Jun 2008 04:19:37 -0300 (ADT) thread-index: AcjG3J34VSJwJ9fJTbq/6leuK6Bryg== Received: from [192.168.1.105] ([82.181.212.226]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 03:20:21 -0400 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Message-ID: <48479381.6020006@enterprisedb.com> Date: Thu, 05 Jun 2008 10:19:29 +0300 From: "Heikki Linnakangas" Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: "Simon Riggs" Cc: "pgsql-hackers" Subject: Re: pg_dump restore time and Foreign Keys References: <1212647003.19964.19.camel@ebony.site> In-Reply-To: <1212647003.19964.19.camel@ebony.site> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2008 07:20:21.0671 (UTC) FILETIME=[9D72CB70:01C8C6DC] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/221 X-Sequence-Number: 119334 Simon Riggs wrote: > I'm guessing that the WITHOUT CHECK option would not be acceptable as an > unprotected trap for our lazy and wicked users. :-) Yes, that sounds scary. Instead, I'd suggest finding ways to speed up the ALTER TABLE ADD FOREIGN KEY. Or speeding up COPY into a table with foreign keys already defined. For example, you might want to build an in-memory hash table of the keys in the target table, instead of issuing a query on each INSERT, if the target table isn't huge. Nothing beats the speed of simply not checking the constraint, of course, but I'd hate to lose the protection it gives. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com