Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M241897=pgsql-hackers-arkari@postgresql.org>)
 id 1W3Ca4-0004h2-L2
 for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Jan 2014 22:35:32 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M241897=pgsql-hackers-arkari@postgresql.org>)
 id 1W3Ca4-0008Kx-41
 for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Jan 2014 22:35:32 +0000
Received: from makus.postgresql.org ([2001:4800:7903:4::125])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <jim@nasby.net>) id 1W3Ca2-0008Kp-Qe
 for pgsql-hackers@postgresql.org; Tue, 14 Jan 2014 22:35:30 +0000
Received: from 99-153-64-76.uvs.austtx.sbcglobal.net ([99.153.64.76]
 helo=noel.decibel.org) by makus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <jim@nasby.net>) id 1W3CZy-0007ww-D8
 for pgsql-hackers@postgresql.org; Tue, 14 Jan 2014 22:35:28 +0000
Received: from decina.local (cpe-24-55-28-132.austin.res.rr.com
 [24.55.28.132])
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (No client certificate requested)
 by noel.decibel.org (Postfix) with ESMTPSA id 754CC6D45D;
 Tue, 14 Jan 2014 22:35:23 +0000 (UTC)
Message-ID: <52D5BBA9.6040708@nasby.net>
Date: Tue, 14 Jan 2014 16:35:21 -0600
From: Jim Nasby <jim@nasby.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
CC: Shigeru Hanada <shigeru.hanada@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
References: 
 <CAEZqfEfVJNptoTSEY3QrQ90K9WD2nxfM+6fsk3YTc1ZXZ1Y5-g@mail.gmail.com>
	<12432.1384406906@sss.pgh.pa.us>
 <CA+Tgmob3ZNDi+P+v3ypHvFN1tD-Bpt8M+0dHFTnCqHxmcNw8aQ@mail.gmail.com>
In-Reply-To: 
 <CA+Tgmob3ZNDi+P+v3ypHvFN1tD-Bpt8M+0dHFTnCqHxmcNw8aQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -0.9 (/)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 11/18/13, 8:36 AM, Robert Haas wrote:
> On the other hand, the performance costs of checking every row bound
> for the remote table could be quite steep.  Consider an update on an
> inheritance hierarchy that sets a = a + 1 for every row.  If we don't
> worry about verifying that the resulting rows satisfy all local-side
> constraints, we can potentially ship a single update statement to the
> remote server and let it do all the work there.  But if we DO have to
> worry about that, then we're going to have to ship every updated row
> over the wire in at least one direction, if not both.  If the purpose
> of adding CHECK constraints was to enable constraint exclusion, that's
> a mighty steep price to pay for it.

A sophisticated enough FDW could verify that the appropriate check already existed in tho foreign side, or it could do something like:

BEGIN;
UPDATE SET ... WHERE <where>
SELECT EXISTS( SELECT 1 WHERE <where> AND NOT (<check condition>) );

And then rollback if the SELECT returns true.

But obviously you can't always do that, so I think there's a place for both true constraints and "suggested constraints".
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers