Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TDRYb-0000KV-G5 for pgsql-performance@postgresql.org; Mon, 17 Sep 2012 02:59:33 +0000 Received: from mail-ob0-f174.google.com ([209.85.214.174]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TDRYX-000632-EA for pgsql-performance@postgresql.org; Mon, 17 Sep 2012 02:59:31 +0000 Received: by obbuo13 with SMTP id uo13so8430247obb.19 for ; Sun, 16 Sep 2012 19:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=L8wWP7NOjF2PGua+tvuIFMHtWVrJRmTAH2Z2Z9Y1Bas=; b=RngdAwTSLaBs2NszhdFn+0AKzluy/3aHebSbcR5QtQEUVz0qtqY9wRtvhK25q1u2hv 4Xh8auBnfOCJDYJaFFYJF7aaD5ny1ZKXLQKdG45RZqnL3eQRDPd6kOP9RhskohJfzi4A YkJJHpiw3hrOJS+wyIhxdKdtaY0DDUIFIZYjR+/QD41uH6xEfhCSOZ/13t2KYJlEGGyo 19DJHXA+SzEHk9apmz4lyWCHQmvCgEBKLL8DprxQwTVRfJOS2b081tpiNb3sjVBVCfT8 P70eEQ0k1k2R8kWU/NWDFFbpxeBdL2+n68wmeWlWE8y8/USvqmVfkzKrseu4Hkc8AiQL 1ONA== Received: by 10.182.72.9 with SMTP id z9mr10407856obu.5.1347850767306; Sun, 16 Sep 2012 19:59:27 -0700 (PDT) Received: from ayaki.localdomain (office1.postnewspapers.com.au. [150.101.171.128]) by mx.google.com with ESMTPS id k3sm9346490obw.4.2012.09.16.19.59.24 (version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 19:59:26 -0700 (PDT) Message-ID: <50569208.8050408@ringerc.id.au> Date: Mon, 17 Sep 2012 10:59:20 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Tom Lane CC: "McKinzie, Alan (Alan)" , "pgsql-performance@postgresql.org" Subject: Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate References: <5055D7FF.2070908@ringerc.id.au> <5055DE3D.4040603@ringerc.id.au> <11998.1347809835@sss.pgh.pa.us> In-Reply-To: <11998.1347809835@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkl0kjRoskOaFe1VFpfRxDfBamvlvK9bDa137NPueC6m6L5nPEG1coyX4uPohR1uacWXFzO X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201209/81 X-Sequence-Number: 47827 On 09/16/2012 11:37 PM, Tom Lane wrote: > Craig Ringer writes: >> Found it, it's in the NOTES for CREATE TABLE. >> http://www.postgresql.org/docs/current/static/sql-createtable.html: > >> When a UNIQUE or PRIMARY KEY constraint is not deferrable, PostgreSQL >> checks for uniqueness immediately whenever a row is inserted or >> modified. The SQL standard says that uniqueness should be enforced only >> at the end of the statement; this makes a difference when, for example, >> a single command updates multiple key values. To obtain >> standard-compliant behavior, declare the constraint as DEFERRABLE but >> not deferred (i.e., INITIALLY IMMEDIATE). Be aware that this can be >> significantly slower than immediate uniqueness checking. > > Note that that is addressing uniqueness constraints, and *only* > uniqueness constraints. Foreign key constraints are implemented > differently. There is no equivalent to an immediate check of a foreign > key constraint --- it's checked either at end of statement or end of > transaction, depending on the DEFERRED property. So there's really no > performance difference for FKs, unless you let a large number of pending > checks accumulate over multiple commands within a transaction. Ah, thanks. I missed that detail. -- Craig Ringer