Message-ID: <4537812A.3060408@ritek.hu>
Date: Thu, 19 Oct 2006 15:44:10 +0200
From: Atesz <atesz@ritek.hu>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: ACCESS EXCLUSIVE lock
References: <4536391E.7040604@ritek.hu>
	<1161185300.8706.82.camel@state.g2switchworks.com>
In-Reply-To: <1161185300.8706.82.camel@state.g2switchworks.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Scott Marlowe wrote:
> What if, a minute or two after the drop contraint, you issue a rollback?
>   
After the DROP CONSTRAINT I insert 4 million rekords into the TABLE b. 
After the inserts I remake the dropped constraints, and commit the 
transaction (P1). This solution is faster then the conventional method 
without the constraint's trick.
In my work the table A is a dictionary table (key-value pairs) with 
100-200 records, and the TABLE b has 20 columns with 10 references to 
TABLE a. So my experience is that I have to drop constraints before the 
4 million inserts and remake those after it.

If there is an error in my transaction (P1) and I have to rollback, 
there isn't problem, because my inserts lost from TABLE b and the 
dropped constraints may be rolled back. In my opinion there isn't 
exclusion between  a dropped constraint (reference from b to a) and a 
select on TABLE a. If I think well the dropped constraint have to seem 
in other transation (for example: P2). And it doesn't have to seem in my 
transaction, because it has already dropped.


Thanks your suggestions!
Regards,
Antal Attila