Message-ID: <3F3CFD41.7020508@pse-consulting.de>
Date: Fri, 15 Aug 2003 17:33:21 +0200
From: Andreas Pflug <pgadmin@pse-consulting.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [GENERAL] 7.4Beta
References: <20030815073521.B19338-100000@megazone.bigpanda.com>
In-Reply-To: <20030815073521.B19338-100000@megazone.bigpanda.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stephan Szabo wrote:

>On Fri, 15 Aug 2003, Andreas Pflug wrote:
>
>  
>
>>Stephan Szabo wrote:
>>
>>    
>>
>>>That really needs to be rewritten to do a single check over the table
>>>rather than running the constraint for every row.  I keep meaning to get
>>>around to it and never actually do. :(  I'm not sure that in practice
>>>you'll get a better plan at restore time depending on what the default
>>>statistics give you.
>>>
>>>      
>>>
>>This is clearly a case for a statement level trigger, as soon as
>>affected rows can be identified.
>>    
>>
>
>Well, I think single inserts might be more expensive (because the query is
>more involved for the table joining case) using a statement level trigger,
>so we'd probably want to profile the cases.
>  
>
This really depends. If a constraint is just a check on the 
inserted/updated column, so no other row needs to be checked, there's no 
faster way then the current row trigger. But FK constraints need to 
execute a query to retrieve the referenced row, and every RDBMS prefers 
to execute a single statement with many rows over many statements with a 
single row, because the first will profit from optimization. And even if 
only a single row is inserted or updated, there's still the need to 
lookup the reference.

Regards,
Andreas